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Abstract 

The benefits of programming in a functional style are well known. In par- 
ticular, algorithms that are expressed as compositions of functions operating on 
sequences/vectors/streams of data elements are easier to understand and modify 
than equivalent algorithms expressed as loops. Unfortunately, this kind of expres- 
sion is not used anywhere near as often as it could be, for at least three reasons: (1) 
Most programmers are less familiar with this kind of expression than with loops; 
(2) Most programming languages provide poor support for this kind of expression; 
and (3) When support is provided, it is seldom efficient. 

In any programming language, the second and third problems can be largely 
solved by introducing a data type called series, a comprehensive set of procedures 
operating on series, and a preprocessor (or compiler extension) that automatically 
converts most series expressions into efficient loops. A set of restrictions specifies 
which series expressions can be optimized. If programmers stay within the limits 
imposed, they are guaranteed of high efficiency at all times. 

A Common Lisp macro package supporting series has been in use for some time. 
A prototype demonstrates that series can be straightforwardly supported in Pascal. 
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1. Sequence Expressions 

The mathematical term 'sequence' refers to a mapping from the non-negative integers 
(or some initial subset of them) to values. Under the name of sequences [5, 36], vectors [23, 
31, 32, 36], lists [36], streams [6, 19, 25, 30], sets [35], generators [18, 48], and flows [34]' 
data structures providing complete (or partial) support for mathematical sequences are 
ubiquitous in programming. 

The most common use for sequence data structures is as mutable aggregate storage. 
Essentially every programming language provides operations for accessing and altering 
the elements of at least one such structure. 

Sequences have another use that is potentially just as important and yet is supported 
by only a few languages. Most algorithms that can be expressed as loops can also be 
expressed as functional expressions manipulating sequences. For example, consider the 
problem of computing the sum of the squares of the odd numbers in a file Data. This 
can be done using a loop as shown in the following Pascal [24] program. 

type FileOfReal = file of Real; 

function FileSumLoop (Data: FileOfReal): Real; 

var Sum: Real; 
begin 

Reset (Data); 
Sum :» 0; 

while not eof(Data) do 
begin 

If Odd(Dataf) then Sum :■ Sum+Sqr(Data|) ; 
Get (Data) 
end; 
FileSumLoop := Sum 
end 

Alternatively, the sum of the squares of the odd numbers in the file can be computed 
ising the sequence expression shown below. This expression assumes that four subrou- 
tines have been previously defined: CollectSum computes the sum of the elements of a 
sequence; MapFn computes a sequence from a sequence by applying the indicated function 
o each element of the input; Chooself selects the elements of a sequence that satisfy a 
predicate; and ScanFile creates a sequence of the values in a file. 

function FileSum (Data: FileOfReal): Real; 
begin 

FileSum := CollectSum(MapFn(Sqr, Chooself (Odd, ScanFile (Data)))) 
end 

For those who are not accustomed to functional programming, the greater familiar- 
ity of the program FileSumLoop may make it appear preferable. However, the program 
FileSum has two important advantages. First, the patterns of computation that are mixed 
tjogether in the loop in FileSumLoop are pulled apart. Second, each of these subcompu- 
tjations is distilled into a subroutine. For example, the pattern of initializing a variable 
tjo and then repetitively accumulating a result by addition is distilled into CollectSum. 
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Because the subcomputations are pulled apart, they can be understood in isolation. 
Th<^ action of the expression as a whole is the composition of the actions of the sub- 
computations. This makes FileSum more self-evidently correct than FileSumLoop. The 
separation of the subcomputations also means that they can be altered in isolation. This 
maces FileSum easier to modify. The distillation of the subcomputations into subrou- 
tines makes FileSum shorter and enhances the reusability of the subcomputations. It also 
enhances reliability in two ways. Since the subcomputations are being explicitly reused 
instead of regenerated by the programmer from memory, there is less chance of error. In 
addition, since each subroutine can be reused many times, it is practical to work very 
hatrrt to ensure that the algorithm used in the subroutine is robust. 

Unfortunately, there are two problems that inhibit most programmers from writing 
programs like FileSum. First, most programming languages provide very few predefined 
procedures that operate on sequences as aggregates, rather than merely operating on their 
individual elements. Second, even in languages such as APL and Common Lisp, where 
a wide range of sequence operations are available, sequence expressions are typically so 
inefficient (2 to 10 times slower than equivalent loops), that programmers are forced to 
use loops whenever efficiency matters. 

The primary source of inefficiency when evaluating sequence expressions is the phys- 
ical creation of intermediate sequence structures. This requires a significant amount of 
spa;e overhead (for storing elements) and time overhead (for accessing elements and pag- 
ing; . The key to solving the efficiency problem is the realization that it is often possible to 
trai Lsform sequence expressions into a form where the creation of intermediate sequence 
stri ctures is eliminated. For example, it is straightforward to transform the expression 
in F ileSum into the loop in FileSumLoop. 

\ transformational approach to the efficient evaluation of sequence expressions has 
bee l used in a number of contexts. For example, it is used by optimizing APL compil- 
ers 11, 21], Wadler's Listless Transformer [38, 39] which can improving the efficiency of 
programs written in a Lisp-like language, and Bellegarde's transformation system [7, 8] 
whi :h can improve the efficiency of programs written in the functional programming lan- 
guage FP [5]. In addition, Goldberg and Paige [17] have shown that the transformational 
approach can be used to improve the efficiency of data base queries. 

Jnfortunately, it is not possible to completely transform every sequence expression 
an efficient loop. There are two basic ways to deal with this problem. First, one 

hide the issue from the programmer and simply transform what can be transformed. 
Seccjnd, one can develop a set of restrictions defining what can be transformed and 
communicate with the programmer about the transformability of individual sequence 
exp] ess ions. 

the hidden approach, which is followed by all the systems above, has the advantage 
that! programmers can benefit from increased efficiency in some situations without having 
to think about efficiency in any situation. However, it makes it difficult for programmers 
to think about efficiency when they want to, because they have no way of knowing for sure 
whether a given sequence expression will be completely transformed. This is significant, 
because sequence expressions typically remain quite inefficient if any part of them fails to 
be transformed. In addition, quite simple changes in an algorithm often suffice to change 
an tintransformable expression into a transformable one. As a result, it is not really a 
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favor to hide the issue of transformability from programmers. 

The most important contribution of the research reported here is a set of restric- 
tions that can serve as a basis for the communicative approach to the transformation 
t>f sequence expressions into loops. As discussed in Section 2, these restrictions identify 
a class of optimizable sequence expressions that can always be completely transformed. 
tThe restrictions are novel in two ways. First, they are explicit. While every system that 
Optimizes sequence expressions implicitly embodies some set of restrictions, the restric- 
tions used are not explicit except in the work of Wadler [40]. Second, the restrictions in 
(Section 2 are less strict than most other sets of restrictions. In particular, they are much 
less strict than Wadler's restrictions. 

Sections 4-6 show how the communicative approach can be used to add comprehensive 
^nd efficient support for sequence expressions into any given programming language. This 
(s done by adding a new sequence data type called series and a preprocessor that can 
transform optimizable series expressions into loops. The support for series utilizes the 
^ptimizability restrictions in two ways. One of the key restrictions is enforced by selecting 
^he set of series operations so that the restriction cannot be violated. The rest of the 
Restrictions are explicitly checked by the preprocessor. Non-optimizable expressions are 
flagged with warning messages and left unoptimized. If users take the time to make 
^ach series expression optimizable, they can have complete confidence that every series 
Expression is efficient. This is facilitated by the fact that simple series expressions that 
|)nly use each series once can always be optimized. 

Section 3 presents the series data type and a broad suite of associated functions, 
purrently, the most comprehensive support for series is in Common Lisp. This imple- 
mentation [46, 47] is presented in Section 4, along with an extended Lisp example showing 
low series expressions can be used. A prototype implementation [28, 45] shows that series 
expressions can also be added into Pascal. This implementation is presented in Section 5, 
ilong with an extended Pascal example of how series expressions can be used. Readers 
ire encouraged to focus on whichever of Sections 4 and 5 discusses the most familiar 
anguage. 

Section 6 presents the algorithms used to transform optimizable series expressions 
into loops. Section 7 concludes by comparing series expressions with related concepts. 
jThe comparison includes both other implementations of sequences and other approaches 
\o expressing loops in ways that are easy to understand and modify. 

Getting Rid of Loops 

To fully appreciate the practical impact of series expressions in general and optimiz- 
ible ones in particular, one must return to the perspective of sequence expressions as a 
rotational variant for loops. The program FileSum is an example based on the Pascal 
implementation of series. The series expression in it is optimizable and is transformed 
into a loop essentially identical to the one in FileSumLoop. As a result, it is not merely 
1 he case that FileSumLoop and FileSum compute the same result using the same abstract 
.ilgorithm; the two programs denote exactly the same detailed computation. Using the 
Expression in FileSum, one gains the advantages of functional form without paying any 
]}>rice in terms of efficiency or anything else, because there is no change in anything other 
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thaji the notation. 

The value of optimizable series expressions as an alternate notation for loops is directly 
relc ted to the percentage of loops that can be profitably replaced by them. Any loop 
can be expressed as an optimizable series expression by converting the sub computations 
use I in it into series operations and composing them together. (At worst, the entire 
loop becomes a single series operation.) The value of doing this depends on how many 
fra£ ments the loop can be decomposed into and how many of these fragments correspond 
to iamiliar computations. In general, the change is advantageous as long as there is at 
least one familiar fragment, because at the least, there is value in separating the familiar 
fror i the unfamiliar. 

\n informal study [41] revealed that 80% of the loops programmers typically write 
are constructed solely by combining just a few dozen familiar looping fragments. (A 
somewhat similar study is reported in [15].) Experience with the Lisp implementation of 
seri ;s expressions indicates that at least 95% of loops contain some familiar computation. 
Girv en this, the practical benefit of optimizable series expressions can be summarized as 
follows: 

Optimizable series expressions are to loops 
as structured control constructs are to gotos. 

Structured control constructs (if., .then. ..else, case, while... do, repeat., .until) 
are not capable of expressing anything that cannot be expressed as gotos. In addition, 
there are probably a few algorithms for which the use of gotos is preferable. Nevertheless, 
in almost every situation, structured control constructs are much better to use than gotos. 
They are better, not because they allow more algorithms to be expressed, but because 
the;|r allow the same algorithms to be expressed in a way that is much easier to understand 
and modify. 

Dptimizable series expressions have the exact same advantage. They do not allow 
algorithms to be expressed that cannot be expressed as loops. However, they allow 
algc rithms to be expressed in a much better way. The only place where the analogy 
witlt structured control constructs breaks down is that while one can argue that gotos 
are ^lever needed, there are definitely some algorithms that can be expressed better as 
loo^s than as optimizable series expressions. 

At the current time, most programs contain one or more loops and most of the inter- 
esting computation in these programs occurs in these loops. This is quite unfortunate, 
sincj* loops are generally acknowledged to be one of the hardest things to understand in 
any I program. If optimizable series expressions were used whenever possible, most pro- 
grai as would not contain any loops. This would be a major step forward in conciseness, 
reac ability, verifiability, and maintainability. 
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2. Optimizable Sequence Expressions 

As noted above, the primary source of inefficiency when evaluating sequence expres- 
sions is the creation of intermediate sequence structures. There are two aspects to this. 
[First, a subexpression may compute a sequence only part of which is used by the rest 
0f the expression. Second, even when all the elements are used, a significant amount 
of space and time overhead is required to construct physical data structures containing 
them. 

The first problem can be overcome by using lazy evaluation [16] to ensure that se- 
quence elements are not computed until they are actually used. (This also makes it easy 
o support unbounded sequences.) However, lazy evaluation does little to assist with the 
|second problem. In particular, in simple situations where the sequence elements are all 
Used, lazy evaluation wastes time and does not save any space. Although the same ele- 
ments are computed, time is wasted, because coordination overhead is required to decide 
When to compute the elements. The same space is used, because each element has to 
|be stored after it is computed. (Otherwise, a later reuse of an element would require 
recomputation.) 

Both of the problems above can be solved by pipelining the evaluation of sequence ex- 
pressions. When this is possible, elements are computed on demand without coordination 
bverhead and do not have to be stored. 

Pefinition 1 (Pipelined) The evaluation of a sequence expression E is pipelined if the 
evaluation proceeds in such a way that the following conditions hold for every sequence S 
computed by any part ofE. First, each element of S is computed at most once. Second, 
When an element is computed, it is used wherever it needs to be used, and then discarded 
before any other element of S is computed. 

The primary implication of the definition above is that, while some of the procedures 
balled by E may buffer sequence elements within themselves, no additional buffering is 
Required when evaluating E. Each sequence is transmitted between the procedure that 
creates it and the procedures that use it, one element at a time. 

When compile-time pipelining is possible, a sequence expression can be evaluated as 
efficiently as a loop. Unfortunately, pipelining is not always possible. Any system that 
<|loes pipelining can only do so for a restricted class of sequence expressions. Whatever 
ijhe system, it is valuable for these restrictions to be made explicit. If in addition, the 
programmer is given feedback about which expressions fail to meet the restrictions, two 
advantages can be obtained. First, the programmer is given a clear picture of which 
Expressions are efficient and which are not. Second, the programmer has the opportunity 
Ho change inefficient expressions so that they can be pipelined. 

It would be nice to have a set of necessary and sufficient restrictions that specifies 
Exactly which sequence expressions can be pipelined. However, there are a number of 
ijeasons why a somewhat stricter set of restrictions are of greater pragmatic benefit. First, 
1jhe restrictions must be associated with practical algorithms that can check whether the 
ijestrictions hold and can perform the pipelining. Second, the restrictions must be simple 
(inough to understand that programmers can succeed in fixing expressions that violate 
them. 
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The primary contribution of the work presented here is a set of five restrictions that 
satisfy the subsidiary goals above without being excessively strict. These restrictions 
defijue a class of optimizable sequence expressions. It can be shown that every optimizable 
seqjience expression can be pipelined at compile time by transforming it into a loop, using 
the | algorithms in Section 6. 

De inition 2 (Optimizable Sequence Expression) An optimizable sequence ex- 
pression is a sequence expression that satisfies the following restrictions: 

1 ) Optimizable sequence expressions must be statically analyzable. 

2) Optimizable sequence expressions must be straight-line computations. 

3 1) Procedures called by optimizable sequence expressions must be preorder. 
A ) Intermediate values in optimizable sequence expressions must be sequences. 
5J) Every non-directed data flow cycle in an optimizable sequence expression 
must be on-line. 

The restrictions in Definition 2 can be divided into three groups. A restriction anal- 
ogous to the first one is required for any optimization that is to be applied at compile 
tim? as opposed to run time. The second restriction greatly simplifies the algorithms 
in Section 6, but is undoubtedly stronger than necessary. It is hoped that it will be 
we2kened in the future. The remaining three restrictions are the theoretical heart of the 
mal ter. 

In this section, programs are discussed from the point of view of data and control flow 
graphs rather than program text. In this representation, procedure calls and data literals 
are represented by nodes. The nodes have labeled ports corresponding to data inputs 
and outputs. There are no limits on the numbers of inputs or outputs. Data flow is 
represented by directed arcs connecting output ports to input ports. A given output can 
be Connected to several inputs. Control flow is modelled by additional arcs connecting 
spe< ial control inputs and outputs. In the context of these graphs, the term sequence 
expression is defined as follows. 



Definition 3 (Sequence Expression) A sequence procedure is a procedure that 
consumes or produces a sequence. A sequence data flow is a data flow arc that transmits 
a sequence. A sequence subexpression is a (not necessarily proper) subset of the nodes 
in a data and control flow graph that can be built up through repetitive application of 
the following two rules. Each node corresponding to a sequence procedure call or literal 
sequence is a sequence subexpression. If there is a sequence data flow from a node in a 
sequence subexpression X to a node in another sequence subexpression Y, then X \JY 

sequence subexpression. A sequence expression is a sequence subexpression that is 

a proper subset of any other sequence subexpression. 
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The Static Analyzability Restriction 

As with most other optimization processes, a sequence expression cannot be pipelined 
at compile time, unless it can be determined at compile time exactly what computation 
' btjing performed. To make sure that this will be possible, it is required that every use 
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of a sequence procedure in an optimizable sequence expression be an explicit call on a 
predefined sequence procedure. This ensures that it will always be clear exactly what 
sequence computation is being performed. 

Similarly, it is required that every sequence value come directly from a sequence 
procedure call. This ensures that it will always be clear exactly how the sequence is 
being computed. Unfortunately, this also implies that a sequence cannot be stored in 
any kind of data structure. This is undoubtedly somewhat stronger than necessary. 

Arbitrary storage of sequences in data structures is bound to block compile-time 
pipelining. However, certain limited cases could be allowed. For instance, one can some- 
times determine how a sequence contained in another sequence is being computed. The 
practicality of this has been demonstrated by compilers for APL [111, Hibol [341 and 
Model [32]. l J ' 

The Straight-Line Restriction 

In the interest of simplicity, optimizable sequence expressions are required to be 
straight-line computations, not subject to any conditional or looping control flow. That 
s to say, it must be the case that whenever a sequence expression is evaluated, every 
procedure call in it is evaluated exactly once. 

While it is likely that looping control flow in sequence expressions must be prohibited, 
simple conditional control flow could probably be allowed. However, this would compli- 
cate pipelining in a number of ways and much of what can be done using conditional 
control flow can be done using operations like Chooself instead. 

The fact that sequence expressions are straight-line computations means that they 
:an be pipelined without worrying about control flow. As a result, control flow is not 
nentioned in the rest of this discussion. 

The Preorder Restriction 

Suppose that a procedure call T uses a sequence computed by another procedure 
oall Q. For the computation of these two calls to be pipelined, two conditions must be 
! atisfied. First, it must be the case that the sequence elements are created and consumed 
one at a time. Second, the elements must be consumed in the same order they are 
< reated. A good way to ensure that this will always be the case is to pick some fixed 
order and require that every sequence procedure process every sequence one element at 
a time in that order. Given a desire to support unbounded sequences, a good order to 
pick is preorder. 

] Definition 4 (Preorder) A sequence procedure is preorder if it processes the elements 
( f each of its sequence inputs and outputs one at a time in ascending order starting with 
ihe first element. 

In this paper, the word 'function' is reserved for referring to mathematical functions 
^hile the word 'procedure' is used to refer to the implementation of a function in a 
ijrogramming language. With that in mind, note that the definition above applies to 
procedures, not functions. It is a property of the way a computation is performed, not 
cjf the mathematical relationship between the input and the output. Any mathematical 
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seqience function can be implemented as a preorder procedure. At worst, one can simply 
real the input elements into a buffer in preorder, compute the result, and then write the 
elei nents of the result in preorder. 

A property that does apply to mathematical functions is the amount of internal 
buf 'ering that is required when implementing the function as a preorder procedure. For- 
tunately, most sequence functions can be implemented as preorder procedures that do 
not require internal buffering of input or output elements. For instance, the procedure 
MapFn operates as follows: it reads one element of each input sequence, applies the in- 
dicated function to them, writes the resulting output element, and then goes on to the 
next group of input elements. 

The only common functions where internal buffering is required are ones that re- 
arrange the input elements (e.g., reversal, rotation, and sorting). In same cases this 
buf 'ering is solely due to the needs of preorder processing. For instance, while preorder 
reversal requires the entire input to be read before the first output element can be pro- 
duced, some non-preorder implementations require no buffering. In other cases (e.g., 
sorl ing) the buffering is required no matter how the operation is implemented. 

The goal of pipelining is the elimination of the external buffering of elements between 
pro :edure calls. The algorithms in Section 6 are applicable no matter how much internal 
butfl ering the individual procedures use. As a result, the restrictions in Definition 2 do 
not place any limits on internal buffering. (This issue is discussed further at the end of 
this section.) 

Nevertheless, using large internal buffers clearly violates the spirit of what pipelining 
is trying to achieve. It is of no benefit to eliminate external buffering if this is replaced 
by internal buffering. Therefore, in the interest of overall efficiency, the functions oper- 
ating on series (see Section 3) are limited to ones that can be implemented as preorder 
procedures without internal buffering of sequence elements. 

The Sequence Intermediate Value Restriction 

Iven if a sequence expression satisfies the three restrictions above, it may still not 
be possible to pipeline its evaluation. The problem is that if a sequence is used in two 
places, the two uses may place incompatible constraints on the times at which sequence 
elements should be computed. 

The following program shows an expression in which this problem arises. (This pro- 
gran, and the others below, are based on the Pascal implementation of series, see Sec- 
5.) The sequence expression in Normal izedMax creates a sequence X of the numbers 
file Data. It then creates a normalized sequence by dividing each number by the 
of the numbers. Finally, the procedure returns the maximum of the normalized 
elen tents. (The procedure Series creates a sequence indefinitely repeating the value of 
its argument. The call on MapFn divides each element of X by this value.) 

function Normal izedMax (Data: FileOf Real) : Real; 

var X: series of Real; 
begin 

X := ScanFile(Data) ; 

NormalizedMax := CollectMax (MapFn (/, X, Series (CollectSum(X)))) 
end 
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The two uses of X place contradictory constraints on the way pipelined evaluation 
must proceed. The procedure CollectSum requires all the elements of X to be produced 
before the sum can be returned and Series requires that its input be available before it 
can start producing its output. However, MapFn requires that the first element of X be 
available at the same time as the first element of the output of Series. For pipelining 
to work, this implies that the first element of the output of Series (and therefore the 
output of CollectSum) must be available before the second element of X is computed. 
Unfortunately, if X contains more than one element, this is impossible. 

The essence of the inconsistency above is the cycle of constraints used in the argument. 
This in turn stems from a non-directed cycle in the data flow graph underlying the 
expression. Figure 2.1 shows the nodes in the sequence expression in NormalizedMax 
and the data flow between them. The nodes are represented by boxes and data flow is 
represented by arrows. Simple arrows indicate the flow of sequences and cross hatched 
arrows indicate the flow of other values. 



The On-Line Cycle Restriction 
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Figure 2.1: The sequence expression in NormalizedMax. 

From the point of view of Figure 2.1, the problem in NormalizedMax can be summa- 
rized by noting that the non-directed data flow cycle has two conflicting parts. In the 
upper part, pipelining requires that each sequence element be used as soon as it is com- 
muted. In the lower part, the non-sequence data flow forces a delay — all of the elements 
nt the left end of the lower part have to be available before any of the elements at the 
right end can be produced. If the upper part also contained a non-sequence data flow, 
l;hen the delays on the two parts would balance. However, if there was a non-sequence 
data flow in the upper part, the expression would be broken into two separate sequence 
Repressions: one on the left and one on the right. 

Based on Definition 3, it can be shown that whenever a non-sequence value created by 

i node in a sequence expression is used by another node (either directly as in Figure 2.1 

or via a chain of computation) the expression will be associated with a non-directed cycle 

ike the one in Figure 2.1. To prevent this problem, it is required that intermediate values 

in optimizable sequence expressions must be sequences. 

This restriction places significant limits on the qualitative character of optimizable 
|equence expressions. In particular, they all have the general form of creating some 
number of sequences, computing various intermediate sequences, and then computing one 
or more non-sequence results. A non-sequence value cannot be used in the intermediate 
(jomputation unless it is the output of a disjoint expression. 
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The On-Line Cycle Restriction 



The last situation that can block pipelining is illustrated in the program OddSum 
below. This program creates a sequence X of the numbers in a file. It then selects the 
ode elements of X and multiplies the ith odd element of X by the ith element of X. Finally, 
it sims the resulting products. 

function OddSum (Data: FileOfReal) : Real; 

var X: series of Real; 
begin 

X := ScanFile(Data) ; 

OddSum := CollectSum(MapFn(*, X, Chooself (Odd, X))) 
end 
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As in the program Normal izedMax, the two uses of X place contradictory constraints 

the way pipelined evaluation must proceed. The key problem is that Chooself is 

inherently unsynchronized in the way it operates. In this example, it produces output 

s only when it reads odd input elements. However, MapFn requires that the ith 

of X be available at the same time as the zth element of the output of Chooself. 

pipelining to work, this implies that the ith element of the output of Chooself must 

available at the same time that Chooself reads the ith element of X. Unfortunately, if 

1 of the first i elements of X are even, this is impossible. 

\s shown in Figure 2.2, the problem in OddSum is fundamentally much the same as the 

1 in NormalizedMax. In particular, it also stems from a non-directed cycle in the 

unc^rlying data flow graph. Like the non-sequence data flow in Figure 2.1, the Chooself 

;ure 2.2 introduces a delay that is not matched in the other part of the cycle. This 

depends on the input data, but may be arbitrarily large. 
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Figure 2.2: The sequence expression in OddSum. 

Jn contrast to OddSum, consider the program CosSum below, which is identical except 
1 Chooself is replaced by MapFn of Cos. A sum is computed of each element of X 
iplied by its cosine. 

function CosSum (Data: FileOfReal): Real; 

var X: series of Real; 
begin 

X := ScanFile (Data) ; 

CosSum :- CollectSum(MapFn(*, X, MapFn(Cos, X))) 
end 



The On-Line Cycle Restriction n 

Even though CosSum has exactly the same data flow graph as OddSum (with Chooself 
Replaced by MapFn of Cos), CosSum can be pipelined without difficulty. The reason is that 
the MapFn of Cos produces an output element every time it reads an input element. There- 
fore, there is no problem synchronizing the arrival of the elements of the two sequence 
inputs of the MapFn of *. 

The comparison of OddSum and CosSum shows that pipelining is blocked in OddSum by 
the delay introduced by Chooself, rather than by the mere existence of a non-directed 
data flow cycle. To develop a good restriction that rules out this problem, one has to 
develop a vocabulary for talking about where delays are introduced. 

Definition 5 (On-Line and OfT-Line) An input or output port of a sequence pro- 
cedure is on-line if and only if it operates in lock step with all the other on-line ports 
of the procedure as follows: The initial element of each on-line input is read, then the 
initial element of each on-line output is written, then the second element of each on-line 
input is read, then the second element of each on-line output is written, and so on. If 
all of the sequence ports of a procedure are on-line, the procedure as a whole is on-line. 
A non-directed cycle of data flow is on-line if every port it passes through is on-line. A 
non-directed cycle passes through an input or output port of a procedure call if and only 
if exactly one data flow arc in the cycle touches the port. (For example, the cycle in 
Figure 2.2 passes through every port it touches except for the output of ScanFile.J If a 
port, procedure, or data flow cycle is not on-line, it is off-line. 

Definition 5 extends the standard definition of the term 'on-line' [1, 22] so that it 
applies to individual ports as well as whole procedures. Like Definition 4, Definition 5 

ipplies to procedures, rather than functions. While, some mathematical functions (e.g., 
choosing elements from a sequence) cannot be implemented in an on-line fashion, many 

:an. For example, since the ith. element of the result of mapping a function is computed 
; iolely from the ith elements of the inputs, it is easy for MapFn to be on-line. 

Returning to the issue of pipelining, it can be shown that if a non-directed data flow 
cycle in an optimizable sequence expression is on-line, the lock step processing of the 
]j>orts involved guarantees that there will not be any conflicts between the constraints 
associated with the cycle. If every non-directed cycle in an expression is on-line, the 
evaluation of the expression can be pipelined using the following divide and conquer 
|ipproach. 

It can be shown that when a sequence expression in which every non-directed data 

low cycle is on-line contains an off-line port, it is always possible to divide the expression 

|ito two non-overlapping subexpressions so that all data flow between the subexpressions 

riginates (or terminates) on the off-line port in question. The expression as a whole can 

e pipelined by pipelining the evaluation of the two subexpressions separately and using 

simplified form of lazy evaluation to interleave the evaluation of the subexpressions in a 

ipelined fashion. The lazy evaluation is simplified because the method for determining 

rhich subexpression to evaluate when is very simple. The first subexpression needs to 

e evaluated when the second subexpression needs to read a new value computed by it. 

Once partitioning based on off-line ports has been applied as many times as possible, 

cine is left with subexpressions where every data flow connects on-line ports. In such a 
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sub expression, pipelining can be achieved by simply evaluating every procedure call in 



loci: 



step, one element at a time. 

The limits imposed by the on-line cycle restriction are softened by the fact that a 

wid 3 range of mathematical sequence functions can be implemented in an on-line way. 

For instance, any preorder procedure that has only one sequence port is trivially on-line. 

Beyjond this, most of the functions in Section 3 can be implemented as on-line procedures. 

Obeying the Restrictions 

n the current implementations of series (see the discussion in the following sections), 
the preorder restriction is implicitly enforced by ensuring that every predefined series 
procedure is preorder and not providing any means for defining series procedures that 
are not preorder. (Note that the composition of two preorder procedures is preorder.) 

The other four restrictions are explicitly checked. Whenever an expression satisfies 
these restrictions, the algorithms in Section 6 are used to transform the expression into 
an ( fficient loop. When they are not satisfied, a warning is issued. In the Pascal im- 
plementation, these warnings are fatal errors. However, in the Lisp implementation, the 
expressions are simply left as is and evaluated/ compiled without optimization. 

' The best approach for programmers to take is to write expressions without worrying 
about the restrictions and then fix the expressions in the event that a problem is reported. 
The virtues of this approach are enhanced by the fact that simple expressions are very 
unli cely to violate any of the restrictions. In particular, it can be shown that if every 
seqi ence procedure in an expression has only one output and sequence outputs are not 
stored in variables, then the sequence intermediate value and on-line cycle restrictions 
cam tot be violated. 

i limilarly, it can be shown that violations of the sequence intermediate value and on- 
cycle restrictions can always be fixed using code copying to break the expression in 
or to break the offending cycle. For instance, the program Normal izedMax can be 
broi ght into compliance with the sequence intermediate value restriction by duplicating 
the call on ScanFile. This breaks the sequence expression into two separate sequence 
expijessions that each satisfy the sequence intermediate value restriction. 

function Normal izedMaxA (Data: FileOf Real) : Real; 

var Sum: Real; 
begin 

Sum := CollectSum(ScanFile(Data)); 

NormalizedMax := CollectMax(MapFn(/, ScanFile (Data) , Series(Sum))) 
end 

It would be possible to automatically introduce code copying to resolve conflicts with 
the sequence intermediate value and on-line cycle restrictions. However, this can lead to 
significant inefficiencies. It is better to leave it up to the programmer to figure out how to 
fix conflicts. For example, the procedure NormalizedMax can be brought into compliance 
mor< efficiently, by realizing that the operations of computing the maximum and dividing 
by t]jie sum commute. 
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function Normal izedMaxB (Data: FileOf Real) : Real; 

var X: series of Real; 
begin 

X :» ScanFile(Data) ; 

Normal izedMax := CollectMax(X)/CollectSum(X) 
end 

This example brings up an important secondary goal underlying the restrictions pre- 
sented here. This goal is to make it easy for programmers to reliably tell which expressions 
are efficient and which are not. It would be better to make every expression efficient. 
However, given that this is not possible, programmers need accurate information in order 
to decide what to do. 

Other Approaches to Restrictions 

The optimizability restrictions presented above are the result of research going back 
twelve years. The basic concept of representing common looping sub computations as op- 
erations on sequences is descended from ideas developed in the Programmer's Apprentice 
project [33, 41]. The first attempt to state a formal set of restrictions appears in [42, 43]. 
A set of restrictions intermediate between the initial ones and the ones presented above 
appear in [44]. 

Optimizability restrictions are implicit in all the work on sequence expression opti- 
mizers. However, these restrictions are typically implicit in the way the optimizers work, 
rather than being explicitly stated. The only other research featuring explicit restrictions 
s that of Wadler [40]. 

The key difference between Wadler's restrictions and the ones presented here is that 
le assumes that procedures can only have one output and only considers the situation 
where two procedures are composed together. This can be straightforwardly generalized 
;o expressions that are tree-like in form— i.e., ones where the output of each function is 
>nly used once. However, it is not applicable to more complex situations. 

Wadler's implicit requirement that expressions be trees rules out non- directed data 
low cycles. This obviates the need for anything like the sequence intermediate value or 
on-line cycle restrictions. However, it is unreasonably limiting. Since it is often possible 
1 o pipeline the evaluation of an expression even though it contains non-directed cycles of 
< lata flow, it is unreasonable (both from the point of view of readability and efficiency) 
l;o require that an intermediate value that is used in n places must always be computed 
ii times. 

The restriction that Wadler explicitly states (i.e., that procedures must be preorder 
listless) is basically equivalent to the preorder restriction stated here, except that it also 
limits the storage used, as discussed below. (Wadler's definition of the term preorder is 
different from the one used here.) 

Another significant difference between Wadler's work and the work presented here is 
that he approaches the problem of efficiency from a different direction. Rather than con- 
s idering pipelining directly, he focuses on the amount of storage required when evaluating 
i in expression. He requires that preorder listless procedures evaluate using a bounded 
c mount of storage (over and above the storage required for the inputs and outputs them- 
£felves) and shows that the composition of two such functions can be evaluated using a 
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botjnded amount of storage (over and above the storage required for the net inputs and 
outputs of the composition). 

It can be shown that when all the procedures called by an optimizable sequence ex- 
pre jsion use bounded storage, the pipelined evaluation of the expression will use bounded 
sto] age. However, it was decided not to introduce a restriction limiting sequence proce- 
durgs to bounded storage for three reasons. First, such a restriction has nothing to do 
wit i pipeline per se. Pipelining can be applied just the same no matter how much storage 
the individual procedures use. The key thing is that pipelining allows the storage require- 
mei its of an expression to be the sum of the storage requirements of the procedures called 
by :t. Second, when considering individual sequence procedures a requirement that they 
use bounded storage is too weak to be useful. As discussed in the section on the preorder 
restriction, one certainly does not want unbounded storage to be used to store input or 
out out elements. (However, what if it is used for some other purpose?) In addition, large 
fixed storage needs are just as much of a practical problem as unbounded ones. What 
is r ;ally needed is for the implementor of the procedure to make a good faith eifort to 
use as little storage as possible. Third, such a restriction cannot be usefully supported, 
bee mse there is no practical way to determine whether a user-defined sequence procedure 
requires unbounded storage. 

\ final difference between Wadler's work and the work presented here is that Wadler 
chone to apply his restrictions to a pre-existing data type (lists). In the approach taken 
her*, a new data type (series) is developed for three reasons. First, since lists cannot 
repiesented unbounded sequences, focusing on lists unduly limits the kind of procedures 
thai can be expressed. Second, lists (and vectors) have evolved a style of use and a 
suit 3 of associated operations that are appropriate for that use. These work well for 
thei r intended use, but are not as useful as they could be from the perspective of writing 
efficient sequence expressions. Developing a new data type makes it possible to create a 

suite of operations that is more appropriate for this purpose. Third, an important 

of the approach being advocated here is the error messages that report unoptimizable 
series expressions. These are important if programmers are to achieve efficiency. However, 
the] would be irritating and counterproductive if they were constantly being reported 
for ist expressions that were not intended to be optimizable. By adding a series data 
type, programmers can benefit from the restrictions when they choose to follow them, 
witljout being prevented from using lists, vectors, and streams in standard ways. 



Series Expressions 15 

$. Series Expressions 

Vectors, lists, and other such data structures differ in how closely they model the 
mathematical concept of a sequence and in the range of associated operations. The 
series data type embodies a set of design decisions that combine full support for the 
mathematical concept of a sequence, a wide range of operations, and high efficiency. As 
llustrated in the next two sections, support for series can be straightforwardly added 
:o any programming language. High efficiency is obtained by using a preprocessor or 
:ompiler extension like the one presented in Section 6. 

Informally speaking, series are like vectors except that they can be unbounded in 
ength. Formally, series are defined by the way they can be operated on. The remainder 
)f this section presents an illustrative selection of these operations as mathematical func- 
;ions. (See [9] for an in depth discussion of the mathematical properties of many of these 
unctions when applied to finite sequences.) The next two sections present procedures 
mplementing these functions in specific programming languages. 

I In the following, lowercase letters (z, y) denote arbitrary values, uppercase letters 
.R, S) denote series, and calligraphic letters (J 7 , V) denote functions and predicates, 
[n addition, special notations are used to denote four of the most basic series functions. 
The construction function, which creates a series containing the indicated elements in 
;he indicated order is denoted using angle brackets, i.e., (ar, y, . . . , z). The concatenating 
unction, which creates a series containing the elements of a series R followed by the 
dements of another series S is denoted using the operator "||", i.e., R \\ S. The tail 
unction, which creates a series containing the elements of a non-empty series S after the 
irst one is denoted by drawing a line over the series, i.e., 5. The head function, which 
•eturns the first element of a non-empty series is denoted by subscripting the series with 
sero, i.e., S . (For convenience, the series used as examples below contain numerical 
Elements. However, any kind of object can be used as a series element.) 

(6,7,8) H(9,10) = (6,7,8,9,10) 

(6,7,8) = (7,8) 

<6,7,8) = 6 

(10,(4,5) o ,20) = (10,4,20) 

Series functions can be divided into three categories: scanners produce series without 
consuming any, collectors compute non-series values from series, and transducers compute 
;eries from series. For instance, the head function is a collector and the concatenating 
unction is a transducer. 

There are two kinds of scanners. Some scanners create a series of the elements in an 

iggregate data structure, for instance, a series of the nodes in a tree. Other scanners 

Create a series based on some formula, for instance, the successive powers of some number. 

The Lisp implementation of series supports 15 scanners. However, one of these (scanning, 

iiee below) can be used to define all the rest. 

Scanning is a higher-order function — a function that takes functions as arguments, 
'fhe first argument is an initial value z, which becomes the first element of the series 
•treated. The second argument is a stepping function ?, which is used to compute each 
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serifes element from the previous element. The third argument is a predicate V, which is 
use I to determine where the series should end. The series created contains the elements 
~ C ( z )i F{F{z)), and so on, up to but not including the first value satisfying V. If no 
vali le satisfies V, the series is unbounded in length. The example computes the powers 
of % that are less than 100. 

scanning^, F, V) = { 9 V „ . , , x iiV ( z ) 

V ; 1 (z) || scanning^*), T, V) otherwise 

scanning(l, \x.x+x, Az.:r>100) = (1,2,4,8,16,32,64) 

There are also two kinds of collectors. Some collectors create an aggregate data 
stri cture containing the elements of a series, for instance, a hash table containing the 
series elements. Other collectors create a summary value computed by some formula 
frori the elements of a series, for instance, their sum. The Lisp implementation of series 
sup Dorts 18 scanners. However, one of these (the higher-order series function collection 
sho vn below) can be used to define all the rest. 

Collection uses a binary function T to combine the elements of a series S together. 
The combination process begins with an initial value z. Typically, z is chosen to be a 
left identity of T. The example computes the sum of a series. 

collection^, JF, S) = { Z „ . , , _ if S = 

J \ collection^*, S ), T, S) otherwise 

collection(0, \xy.x+y, (1,2,3)) = 6 

Transducers are more complex than scanners or collectors. In particular, there is no 
transducer that serves as a basis for the rest. Nevertheless, four key higher-order 

trar sducers support wide classes of common transduction operations. 

Collecting is the same as collection except that it returns a series of partial results, 

rati er than just a final value. The length of the output is the same as the length of S. 

The] example computes a series of partial sums. 

collecting^, T, S) = < 9 , if S = 

^ I <F(z, So)) || collecting^*, 5 ), T, ~S) otherwise 

collecting^, A xy.x+y, (1,2,3)) = (1,3,6) 

] 3y far the most commonly used series function is mapping, which maps a function 
T over some number of series producing a series of the results. Each element of the 
output is computed by applying T to the corresponding elements of the inputs. The 
length of the output is the same as the length of the shortest input. The example adds 
the torresponding elements in two series. 



mapping^, S\ ..., S n ) = < 



' if any S { = () 

<^(5J, ...,5J)>|| . 

I mapping^, 5\ . . . , ^) ° therW1Se 

mapping(Aary.a:+y, (1,2,3), (4,5,6,7)) = (5,7,9) 
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Truncating cuts off a series by testing each element with a predicate and discarding 
Ml the remaining elements as soon as an element satisfying the predicate is encountered. 
The example truncates a series at the first negative element. 

truncating^, S) = f <> . if S = {) or V(S ) 

6V ' \ {So) || truncating(^>, £) otherwise 

truncating(A x . x<0, (0,3,2,-7,1,-1)) = (0,3,2) 

Mingling combines two series into one under the control of a comparison predicate. 
(The comparison is performed as indicated to ensure that the combination will be stable — 
jf two elements are considered equal by the comparison predicate, the element from R 
(vill precede the element from S in the result. The example shows the combination of 
two sorted series into a sorted result. 

R if S = () 

mingling^, 5, V) = j ^ || minglingffi ^ P) '^(l Eo) 

(S ) || mingling(i?, S, V) otherwise 
mingling((l,3,7), (2,4,5), Xxy .x<y) = (1,2,3,4,5,7) 

Choosing selects the elements of a series that satisfy a predicate. The example picks 
<j>ut the negative elements of the input. 



choosing^, S) 



_ if 5=() 

(S ) || choosing(P, S) if V(S ) 
choosingfP, S) otherwise 

choosing(Aar.a:<0, (0,3,2,-7,1,-1)) = (-7,-1) 

In addition to the higher-order transducers above, some specific transducers are im- 
portant as well. The function spreading is a quasi-inverse of choosing. Spreading takes a 
jjeries of non-negative integers R and a series of values 5, and creates a series containing 
ijhe elements of S. In the output, the elements of S are spread out by interspersing them 
Vth copies of z. If the eth element of R is n, then the zth element of S is preceded by 
iji copies of z. Taken together with the example above, the example below illustrates the 
ijelationship between choosing and spreading. 



spreading(i2, 5, z) = 



' if R = () or S = () 

(So) || spreading(#, 5, z)__ if Rq = 

k (z) || spreading((i?o-l) || i?, 5, z) otherwise 

spreading((3,l), (-7,-1), 0) = (0,0,0,-7,0,-1) 



Subseries is a generalization of the tail function. It creates a series of the elements of 
its input from the nth up to but not including the mth. The first element in a series has 
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input runs out of elements. The example takes a chunk out of the middle of a series 
subseries(5, n, m) = < 
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index 0. If m is greater than or equal to the length of S, output stops as soon as the 



if m = or S = () 

subseries(^, n— 1, m— 1) if n > 

k (5 ) || subseries(£, 0, ra-1) otherwise 



subseries«l, 1,2, 2,3,3,4,4), 2, 5) = (2,2,3) 

iThe function chunk is different from the ones above, because it can produce more than 
output. It has the effect of breaking a series S into (possibly overlapping) chunks of 
width m > 0. Successive chunks are displaced n > elements to the right, in the manner 
of a moving window. Chunk produces m output series. The zth chunk is composed of 
the z'th elements of the m outputs. Suppose that the length of S is /. The length of each 
output is [1 + (l-m)/n\ . By itself, chunk may appear somewhat unusual, however, it 
is quite useful in combination with other transducers. For instance, the example shows 
hovf chunk could be used as part of the computation of a moving average. (Programming 
lan| ;uages differ in the mechanisms that could be used to channel the outputs of chunk 
to the inputs of mapping.) 

chunk(m, n, S) = R 1 , ..., R m where 

R k = chunk(l, n, subseries(5', k—1, oo)) 

chunk(l, n,5) = 1 *' „ L w if S = <> 

( Wo) || chunk(l, n, subsenes(5, rc, oo)) otherwise 

chunk(2, ,1,(1,5,3,7)) = (1,5,3), (5,3,7) 
mapping(Aay.(:r+y)/2, (1,5,3), (5,3,7)) = (3,4,5) 

Jhe list of functions above can be viewed as a recommendation for the kind of func- 
tionis that can profitably be supported in conjunction with a sequence data type. As 
discussed in Section 7, some languages (e.g., APL) support most of these functions; oth- 
e.g., Pascal) support almost none of them. 

The list of functions is also interesting for what it does not contain. To start with, it 
doe; not contain functions for accessing arbitrary series elements or altering the value of 
series elements. This reflects the fact that, unlike vectors or lists, series are not intended 
to b e used as mutable data storage. 

].n addition, the choice of functions is significantly influenced by the optimizability 
rest rictions in the last section. The list only includes functions that can be implemented 
as preorder procedures using small fixed amounts of internal storage. (The only common 
functions ruled out by this criteria are ones like reversal, rotation, and sorting that 
rearrange the order of the elements of a sequence.) The list also favors functions that 
can be implemented as on-line procedures, because these are more useful in optimizable 
expiessions. (The only functions in the list that require off-line implementation are 
concatenating, tail, mingling, choosing, spreading, subseries, and chunk.) 
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4. A Common Lisp Implementation 

Series can be added into essentially any programming language by adding an imple- 
mentation of the series data structure and defining a set of procedures supporting the 
peries functions in Section 3. The optimization of series expressions can be supported by 
a preprocessor (see Section 6). It is in the nature of Lisp, that both of these things are 
^asy to do using a macro package. Such a macro package has been in regular use for a 
(number of years and is generally available (see [46, 47]). 

Series. In the Lisp implementation, series are implemented lazily using closures. A 
jseries has a procedural part and a data part. The procedural part is a generator [18, 29] 
capable of computing the elements one by one. The data part records the elements 
Computed so far. 

The elements of a series are accessed using a second generator that enumerates the 
Elements in the data part of the series and then uses the procedural part to compute 
friore elements as needed. Each time the generator is called, it returns another element 
jn the series. The generator takes a procedure argument that specifies what to do when 
the series runs out of elements. 

The two-level generation scheme above ensures that: elements are not computed 
until needed, no element is computed twice, and each user of a series can access all 



(setq f irst5 • Implementation of (1,2, 3,4, 5>. 

(let <(x 0)) ' 

(list #' (lambda (at-end) 

(if (< x 5) (setq x (+ x 1)) (funcall at-end)))))) 

(defun generator (s) ; Returns a generator for the elements of a series, 
(let ((g (car s))) 
#' (lambda (at-end) 

(when (null (cdr s)) 
(setf (cdr s) 

(block nil 

(list (funcall g #' (lambda () (return T) )))))) 
(if (not (eq (cdr s) T)) 
(car (setq s (cdr s))) 
(funcall at-end))))) 

(defun choose- if (p s) ; Implementation of choosing("P, S). 
(let ((gen (generator s))) 
(list #» (lambda (end-action) 

(loop (let ((x (funcall gen end-action))) 

(if (funcall p x) (return x) ))))))) 

(defun collect-sum (s) ; Implementation of collection(0, \xy.x+y, S). 
(let ((gen (generator s)) 
(sum 0)) 
(loop (let ((x (funcall gen #' (lambda () (return sum))))) 
(setq sum (+ sum x)))))) 

(collect-sum (choose-if #'oddp first5)) => 9 

Figure 4.1: Illustration of the Lisp implementation of unoptimized series. 
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20 A Common Lisp Implementation 

the elements. For those familiar with Lisp, Figure 4.1 illustrates the implementation of 

seri ;s data structures. The same basic implementation approach is used in the language 

Seqie [19]. 

The closure implementation of series is effective and straightforward; However, it is 
very efficient. No effort has been expended on producing a more efficient imple- 

mei.tation, because the focus of series expressions is on the situations where they can 

be optimized, eliminating the physical representation of series altogether. In situations 

whe re optimization is impossible, it is usually better to represent a sequence as a vector 

or 1 st than as a series. 

The protocol above for obtaining a generator for the elements of a series and thence 
elements themselves is not an exported part of the series implementation. Users must 

mai dpulate series using the series procedures below. This is important in the interest of 

opt: mizability in general and static analyzability in particular. 

Series procedures. The series functions described in Section 3 are all supported 

isp procedures as shown in Figure 4.2. In addition, the # macro character syntax 

y ... z) is provided for reading and printing literal series. The difference between 

mak j-series and #Z is that the arguments to #Z are implicitly quoted, while the arguments 

to n|ake-series are evaluated one at a time as needed. 



(catenate (make-series 1 (+2 2)) #Z(7 8)) => #Z(1 4 7 8) 
(collect-first (choose-if t'oddp #Z(8 -7 6 -1))) =>- -7 
(subseries (mingle #Z(1 5 9) #Z(2 6 8) #'<) 2 4) =$► #Z(5 6) 
(multiple-value-bind (xs ys) (chunk 2 1 #Z(1 5 3 7)) 

(map-fn T #> (lambda (x y) (/ (+ x y) 2)) xs ys)) => #Z(3 4 5) 

'V he higher-order procedures implementing scanning, collecting, mapping, truncating, 
collection are extended so that they can accept multiple series arguments and produce 
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(x,y 1 ...,z) (make-series x y . . . z) 

So (collect-first 5) 

S (subseries S 1) 

R II S (catenate R S) 

scanning^, T, V) (scan-fn type Z T V) 

collection^, T, S) (collect-fn type Z T S 1 ... S n ) 

collecting^, T, S) (collect ing-fn type Z T S 1 . . . S n ) 

mapping^, S\ ..., S n ) (map-fn type T S 1 ... S n ) 

truncatingCP, S) (until-if V S 1 . . . S n ) 

mingling^, 5, V) (mingle R S V) 

choosing^, S) (choose-if V S) 

spreading(#, 5, z) (spread R S z) 

subseries^, n, m) (subseries S n m) 

chunk(m, n, S) (chunk m n S) 

Figure 4.2: Lisp support for series functions. 
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multiple values. (Series of tuples could be used to get the same effect in any given 
situation. However, using multiple series values is usually more convenient and almost 
always more efficient than using tuples.) 

The examples below illustrate the Lisp procedure scan-fn, which supports scanning. 
In the second example, a two-valued stepping procedure is used and two series are re- 
turned (the unbounded series of natural numbers and a series of their partial sums). 
While scanning is in progress, two internal states are maintained. The stepping pro- 
cedure must accept as many values as it returns. Each of these values is treated as a 
separate state variable. 

(scan-fn 'list #' (lambda () ' (a b c d)) #'cddr #'null) 
=>> #Z((a bed) (c d)) 

(scan-fn » (values integer integer) 
#' (lambda () (values 1 1)) 
#' (lambda (i sum) 

(setq i (+ i 1)) (values i (+ sum i)))) 
=> #Z(1 2 3 4 ...) and #Z(1 3 6 10 ...) 

Three other features of scan-fn are worthy of note. First, a new first argument is 
ntroduced, which specifies the type (or types) of the values returned by the stepping 
procedure. Given the lack of typing information in Lisp, this argument is necessary 
:o ensure that the number of arguments returned by the stepping procedure can be 
ietermined at compile time. Second, the initial value is replaced by a procedure that 
returns the initial values. This is convenient in situations where multiple initial values 
ire needed. Third, the predicate argument is made optional. Omitting it is the same as 
supplying a predicate that is not true of any value. The first and second extensions are 
ipplied to collect -fn, collect ing-fn, and map-fn as well as scan-fn. 

As a convenience to the user, a number of specific scanners are provided in addition 
;o scan-fn. These include: series which creates a series indefinitely repeating a given 

value, scan which enumerates the elements in a list, vector, or string, scan-range which 
enumerates the integers in a range, and scan-plist which creates a series of the indicators 
n a property list along with a second series containing the corresponding values. The 
irst argument of scan specifies the type of object to be scanned. If omitted, the type 

defaults to list. 

(series "test") =>* #Z("test" "test" "test" ...) 

(scan '(a b c)) =$► #Z(a b c) 

(scan 'vector '#(a b c)) =>• #Z(a b c) 

(scan 'string "Tuz") =$► #Z(#\T #\u #\z) 

(scan-range :from 1 :upto 3) =>- #Z(1 2 3) 

(scan-plist '(a 1 b 2)) => #Z(a b) and #Z(1 2) 

Similarly, a number of specific collectors are provided including: collect which cora- 
Hines the elements of a series into a list, vector, or string, collect-sum which adds up the 
cjlements of a series, collect-length which returns the number of elements in a series, 
*jnd collect-last which returns the last element of a series (or an optional default value 
if the series is empty). The first argument of collect specifies the type of object to be 
ijroduced. If omitted, the type defaults to list. 
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(collect #Z(a be)) =>• (a b c) 

(collect 'simple- vector #Z(a b c)) =^ #(a b c) 

(collect 'string #Z(#\T #\u #\z)) =>► "Tuz" 

(collect-sum #Z(1 3 2)) ^ 6 

(collect-length #Z("fee" "fi" "fo" "fum")) => 4 

(collect-last #Z(»'fee" "fi" "fo" "fum")) => "fum" 

(collect-last #Z() "none") => "none" 

inally, a number of additional transducers are provided including: previous (based 
on ii ap-f n) which takes in a series and shifts it over one element by inserting the indicated 
valie at the front and discarding the last element, choose (based on choose-if) which 
sele :ts the elements of its second argument that correspond to non-null elements of its 
first argument, and positions (also based on choose-if) which returns the positions of 
the [ion-null elements in a series. If given only one argument, choose returns the non-null 
elerients of this series. 

(previous #Z("fee" "fi" "fo" "fum") " ") =>► #Z(" " "fee" "fi" "fo") 

(choose #Z(T nil T) #Z(1 2 3)) => #Z(1 3) 

(choose #Z(nil 3 4 nil)) =>► #Z(3 4) 

(positions (map-fn #'oddp #Z(1 2356 8))) => #Z(0 2 3) 

Convenient support for mapping. In cognizance of the ubiquitous nature of 
maj ping, the Lisp series implementation provides three mechanisms that make it easy 
to e Kpress particular kinds of mapping. The # macro character syntax #M^* converts a 
procedure T into a transducer that maps T. 

(#Msqrt #Z(4 16)) = (map-fn T #>sqrt #Z(4 16)) => #Z(2 4) 

The form mapping can be used to specify the mapping of a complex computation over 
or more series without having to write a literal lambda expression. It has the same 
bas^p syntax as let. For example, 

(mapping ((x (scan '(2 -2 3)))) 
(expt (abs x) 3)) =^ #Z(8 8 27) 

is tile same as 

(map-fn T #' (lambda (x) (expt (abs x) 3)) 
(scan >(2 -2 3))) => #Z(8 8 27) 

'phe form iterate is the same as mapping except that the value nil is always returned. 

(iterate ((x (scan '(2 -2 3)))) 

(if (plusp x) (prinl x))) =*► nil <after printing "23" > 

To a first approximation, iterate and mapping differ in the same way as mapc and 
mapcar. In particular, like mapc, iterate is intended to be used in situations where the 
bod f is being evaluated for side effect rather than for its result. However, due to the lazy 
evaluation nature of series, the difference between iterate and mapping is more than just 
a qt estion of efficiency. If mapping is used in a situation where the output is not used, no 
computation is performed, because series elements are not computed until they are used. 

] tested loops. The equivalent of a nested loop is expressed by simply using a series 
expiession in a procedure that is mapped over a series. This is typically done using 
mapijing. In the example, a list of sums is computed based on a list of lists of numbers. 



one 



A Common Lisp Implementation 23 

(let ((data »((1 2 3) (4 5 6) (7 8)))) 
(collect 

(mapping ((number-list (scan data))) 

(collect-sum (scan number-list))))) =£- (6 15 15) 

User-defined series procedures. As shown by the definitions of collect-sum 
and mapping below, the standard Lisp forms defun and defmacro can be used to de- 
fine new series procedures. However, the Series macro package must be informed when 
a series procedure is being defined with defun. This is done by using the declaration 
optimizable-series-function. No special declaration is required when using defmacro. 

(defun collect -sum (numbers) 

(declare (optimizable-series-function) ) 
(collect-fn 'number #> (lambda () 0) #'+ numbers)) 

(defmacro mapping (var-value-pair-list ftbody body) 
(let* ((pairs (scan var-value-pair-list)) 
(arg-list (collect (#Mcar pairs))) 
(value-list (collect (#Mcadr pairs)))) 
'(map-fn T #' (lambda , arg-list ,« body) ,<B value-list))) 

Example. The following example shows what it is like to use series expressions in a 
realistic programming context. The example consists of two parts: a pair of procedures 
that convert between sets represented as lists and sets represented as bits packed into an 
integer and a graph algorithm that uses the integer representation of sets. 

Sets over a small universe can be represented very efficiently as binary integers where 
sach 1 bit in the integer represents an element in the set. Here, sets represented as binary 
integers are referred to as bit sets. 

Common Lisp provides a number of bitwise operations on integers, which can be used 
:o manipulate bit sets. In particular, logior computes the union of two bit sets while 
Logand computes their intersection. 

The procedures in Figure 4.3 convert between sets represented as lists and bit sets. 
To perform this conversion, a mapping has to be established between bit positions and 
potential set elements. This mapping is specified by a universe. A universe is a list of 
Elements. If a bit set integer b is associated with a universe w, then the ith element in u 

(defun bset->list (bset universe) 

(collect (choose (#Mlogbitp (scan-range :from 0) (series bset)) 
(scan universe)))) 

(defun list->bset (items universe) 

(collect-fn 'integer #' (lambda () 0) #'logior 
(mapping ((item (scan items))) 

(ash 1 (bit-position item universe))))) 

(defun bit-position (item universe) 

(or (collect-first (positions (#Meq (series item) (scan universe)))) 
(1- (length (nconc universe (list item)))))) 

Figure 4.3: Converting between lists and bit sets. 
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(defun collect-logior (bsets) 

(declare (optimizable-series-f unction) ) 
(collect-fn 'integer #' (lambda () 0) #'logior bsets)) 

(defun collect-logand (bsets) 

(declare (optimizable-series-f unction) ) 
(collect-fn 'integer #' (lambda () -1) #'logand bsets)) 

Figure 4.4: Operations on series of bit sets. 

is ii the set represented by b if and only if the ith. bit in 6 is 1. For example, given the 
universe (a b c d e), the integer #b010il represents the set {a,b,d}. (By Common Lisp 
convention, the Oth bit in an integer is the rightmost bit.) 

3iven a bit set and its associated universe, the procedure bset->list converts the bit 
set nto a set represented as a list of its elements. It does this by scanning the elements 
in the universe along with their positions and constructing a list of the elements that 
correspond to Is in the integer representing the bit set. (When no :upto argument is 
sup )lied, scan-range counts up forever.) 

The procedure list->bset converts a set represented as a list of its elements into a 

set. Its second argument is the universe that is to be associated with the bit set 
erected. For each element of the list, the procedure bit -position is called to determine 
whi;h bit position should be set to 1. The procedure ash is used to create an integer 
wit] i the correct bit set to 1. The procedure collect-fn is used to combine the integers 
con esponding to the individual elements together into a bit set corresponding to the list. 

The procedure bit -position takes an item and a universe and returns the bit position 
con esponding to the item. The procedure operates in one of two ways depending on 
whether or not the item is in the universe. The first line of the procedure contains a 
seri ;s expression that determines the position of the item in the universe. If the item is 

in the universe, the expression returns nil. (The procedure collect-first returns 

if it is passed an empty series.) 

f the item is not in the universe, the second line of the procedure adds the item onto 

end of the universe and returns its position. The extension of the universe is done 
by 5 ide effect so that it will be permanently recorded in the universe. 

figure 4.4 shows the definition of two collectors that operate on series of bit sets. The 
first procedure computes the union of a series of bit sets, while the second computes the 
intersection. 

Live variable analysis. As an illustration of the way bit sets might be used, consider 
following. Suppose that in a compiler, program code is being represented as blocks 
of si raight-line code connected by possibly cyclic control flow. The top part of Figure 4.5 
shows the data structure that represents a block of code. Each block B has several pieces 
of ii formation associated with it. Two of these pieces of information are the blocks that 
can branch to B and the blocks B can branch to. A program is represented as a list of 
blocks that point to each other through these fields. 

In addition to control flow information, each structure contains information about 
the (vay variables are accessed. In particular, it records the variables that are written by 
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(def struct (block (: cone-name nil)) 

predecessors ; Blocks that can branch to this one. 

successors ;Blocks this one can branch to. 

written ; Variables written in the block. 

USGd ; Variables read before written in the block. 

live ; Variables that must be available at exit, 

temp) ; Temporary storage location. 

(defun determine-live (program-graph) 
(let ((universe (list nil))) 

(convert-to-bsets program-graph universe) 
(perform-relaxation program-graph) 
(convert-from-bsets program-graph universe)) 
program-graph) 

(def struct (temp-bsets (: cone-name bset-)) 
used written live) 

(defun convert-to-bsets (program-graph universe) 
(iterate ((block (scan program-graph))) 
(setf (temp block) 

(make-temp-bsets 

:used (list->bset (used block) universe) 

: written (list->bset (written block) universe) 

:live 0)))) 

(defun perform-relaxation (program-graph) 
(let ((to-do program-graph)) 
(loop 

(when (null to-do) (return (values))) 
(let* ((block (pop to-do)) 

(estimate (live-estimate block))) 
(when (not (= estimate (bset-live (temp block)))) 
(setf (bset-live (temp block)) estimate) 
(iterate ((prev (scan (predecessors block)))) 
(pushnew prev to-do))))))) 

(defun live-estimate (block) 
(collect-logior 

(mapping ((next (scan (successors block)))) 
(logior (bset-used (temp next)) 

(logandc2 (bset-live (temp next)) 

(bset-written (temp next))))))) 

(defun convert-from-bsets (program-graph universe) 
(iterate ((block (scan program-graph))) 
(setf (live block) 

(bset->list (bset-live (temp block)) universe)) 
(setf (temp block) nil))) 

Figure 4.5: Live variable analysis. 
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block and the variables that are used by the block (i.e., either read without being 

ten or read before they are written). An additional field (computed by the procedure 
dert ermine-live discussed below) records the variables that are live at the end of the 
block. (A variable is live if it has to be saved, because it can potentially be used by a 
following block.) Finally, there is a temporary data field, which is used by procedures 
(sui:h as determine-live) that perform computations involved with the blocks. 

The remainder of Figure 4.5 shows the procedure determine-live, which given a 
program represented as a list of blocks, determines the variables that are live in each 
bloi:k. To perform this computation efficiently, the procedure uses bit sets. The procedure 
operates in three steps. The first step (convert-to-bsets) looks at each block and sets 
up im auxiliary data structure containing bit set representations for the written variables, 
the used variables, and an initial guess that there are no live variables. This auxiliary 
structure is defined by the third form in Figure 4.5 and is stored in the temp field of the 
block. The integer represents an empty bit set. 

The second step (perform-relaxation) determines which variables are live. This is 
done by relaxation. The initial guess that there are no live variables in any block is 
successively improved until the correct answer is obtained. 

The third step (convert-from-bsets) operates in the reverse of the first step. Each 
block is inspected and the bit set representation of the live variables is converted into a 
list, which is stored in the live field of the block. 

On each cycle of the loop in perform-relaxation, a block is examined to determine 
whether its live set has to be changed. To do this (see the procedure live-estimate), 
the successors of the block are inspected. Each successor needs to have available to it 
the variables it uses, plus the variables that are supposed to be live after it, minus the 
variables it writes. (The procedure logandc2 takes the difference of two bit sets.) A new 
estimate of the total set of variables needed by the successors as a group is computed by 
using collect-logior. 

If this new estimate is different from the current estimate of what variables are live, 
then the estimate is changed. In addition, if the estimate is changed, perform-relaxation 
has to make sure that all the predecessors of the current block will be examined to see 
whejher the new estimate for the current block requires their live estimates to be changed, 
is done by adding each predecessor onto the list to-do unless it is already there. As 
as the estimates of liveness stop changing, the computation stops. 
Summary. Figure 4.5 is a particularly good example of the way series expressions 

intended to be used in three ways. First, all the series expressions are optimizable. 
Secdnd, series expressions are used in a number of places to express computations that 

d otherwise be expressed less clearly as loops or less efficiently using operations on 

or vectors. Third, the main relaxation algorithm in perform-relaxation is expressed 

loop. This is done, because the data flow in this algorithm prevents it from being 
decomposed into two or more fragments. This highlights the fact that optimizable series 
expressions are not intended to render iterative programs entirely obsolete, but rather to 
provjde a greatly improved method for expressing the vast majority of loops. 
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5. A Pascal Implementation 

Series can be added to Pascal in much the same way as they are added to Lisp. A 
prototype system has been constructed that demonstrates this [28, 45]. However, the 
prototype is written in Lisp rather than Pascal and only supports optimizable series 
expressions. A fatal error is issued whenever optimization is blocked. Although less 
complete than the approach of the Lisp implementation, this still allows loops to be 
replaced by optimizable series expressions. 

Series. The Pascal series preprocessor supports the declaration of series in analogy 
with array declarations as shown below. (This is the only syntactic extension required to 
support series. Further, the output of the preprocessor is standard Pascal without any 
references to series.) In line with the general philosophy of Pascal, it is required that all 
the elements of a series have the same type. However, the length of a series is not part 
of its type. This is important to facilitate the definition of series procedures operating 
on series of arbitrary length. 

type Integers * series of Integer; 
var InputData: series of Real; 

Series procedures. The series functions described in Section 3 are all supported by 
Pascal procedures as shown in Figure 5.1. In general, these have the same names as the 
corresponding Lisp procedures with any hyphens removed (e.g., scan-fn becomes ScanFn). 
Since Pascal does not support the concept of a function procedure that returns multiple 
values, the outputs of chunk are turned into arguments. (The examples in [28, 45] show 
an obsolete set of names linked to an earlier Lisp implementation of series.) The Pascal 
implementation does not provide a syntax for series literals. (The mathematical syntax 
is used in the examples below.) 



Series Function Pascal Implementation 

(x,y,...,z) MakeSeriesCz, y t ..., z) 

So CollectFirstCS) 

S SubseriesCS, 1) 

R II S Catenate (R, S) 

scanning^, T, V) ScanFn(z, T t V) 

collection^, T, S) CollectFnCz, T, S) 

collecting^, T, S) Collect ingFn(z, T, S) 

mapping^, S 1 , ..., S n ) MapFnCF, S 1 , ..., S n ) 

truncatingCP, $) Truncatelf (V , S) 

mingling( J R, S, V) Mingle (i?, S, V) 

choosing(P, S) Chooself (P, S) 

spreading(i?, S, z) Spread (R, S, z) 

subseries(S, n, m) Subseries(5, n, m) 



chunk(m, n, S) Chunk(m, n, S, R 1 , .... R m ) 

Figure 5.1: Pascal support for series functions. 
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Catenate(MakeSeries(l, 2+2), (7,8)) => ( 1,4, 7,8) 

CollectFirst(ChooseIf (odd, (8,-7,6,-l))) =>> -7 

Subseries(Mingle((l,5,9>, <2,6,8>, <)) 2 4) => (5 6> 

Chunk(2, 1, (1,5,3,7), Xs, Ys) => Xs :* (l,5,3> and Ys := (5,3,7) 

MapFn( Average, Xs, Ys) => (3,4,5) 

function Average (x,y: Integer): Integer; 

begin 

Average := (x+y)/2 
end; 

The Pascal implementation does not extend the higher-order procedures over their 
specifications in Section 3 for two reasons. Given the strong typing in Pascal, the pre- 
processor can obtain type information without needing type arguments. Since, Pascal 
doe 3 not support the concept of multiple return values, some other method needs to be 
employed to avoid the need for tuples. 

The procedures in Figure 5.1 do not follow the usual Pascal restrictions on the pa- 
rameters of procedures. Some of the procedures allow the number of arguments they 
rea ive to vary and they all allow considerable flexibility in the types of their arguments. 
This is important because the series procedures are inherently generic in character. For 
instance, MapFn is naturally applicable to any number and any type of series as long as 

element types are compatible with the procedure being mapped. 

Due to their generic nature, the procedures in Figure 5.1 could not be implemented 
as user-defined procedures in Pascal. However, as an extension to the language, they 
do not violate the spirit of Pascal. In particular, the predeclared Pascal procedures are 
generic in exactly the same way. Several (e.g., Read and Write) allow variable numbers 
of arguments and most of them are applicable to more than one type of object. Using 
a more flexible language such as Ada [50], it would be possible to implement (at least 
most of) the higher-order series functions as user-defined procedures. 

All of the specific scanners, collectors, and transducers from the Lisp implementation 
are applicable to Pascal are supported by the Pascal implementation as well. Given 

strong typing in Pascal, Scan and Collect do not need type arguments. Since Pascal 

sets, but not lists, these functions apply to sets and not lists. In keeping with 

general style of Pascal, Collect takes the destination vector/string/set as its first 
argument rather than returning an aggregate value. 

Series ('test') => ('test' , 'test' , 'test' , ...) 
Scan('Tuz') =£► ('T' , 'u' , 'z') 
Scan ([Mon, Wed, Fri]) =>- (Mon,Wed,Fri) 
ScanRangeCl, 3) => (l,2,3) 

Collect (X, ('T','u','z')) { Places 'Tuz' in X. } 

CollectSum((l,3,2)) => 6 

CollectLength((»fee','fi',»fo',»fum')) => 4 
CollectLast(('fee','fi','fo','fum')) =>► 'fum' 
CollectLast((), 'none') =>► 'none' 

Previous (('fee' 'fi' 'fo' »fum'), ' >)=*►(> ' , 'fee' , 'f i' , 'fo') 
Choose ((true, false, true), (l,2,3)) =>> (l,3) 
Positions (MapFn (Odd, (1,2,3,5,6,8))) =>> #Z(0 2 3) 
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Implicit mapping. To avoid making syntactic extensions, the Pascal implemen- 
tation does not support constructs analogous to the Lisp forms mapping and iterate. 
Towever, it supports a related concept that is in many ways even more useful. Whenever 
non-series procedure is applied to a series, it is automatically mapped over the elements 
)f the series. For example, in the expression below, Sqr is automatically mapped over 
;he series of numbers created by scanning the set. 

CollectSum(Sqr(Scan( [2,4] ))) 

= CollectSum(MapFn(Sqr, Scan([2,4] ))) =>• 20 

The key virtue of implicit mapping is that it reduces the number of helping procedures 
hat have to be defined. For instance, in the example of a moving average above, you 
ban write the following instead of denning a procedure Average and explicitly mapping 
it. 

Chunk(2, 1, (1,5,3,7), Xs, Ys) ; (Xs+Ys)/2 =$► (3,4,5) 

The concept of implicit mapping is completely separate from the other concepts as- 
sociated with series expressions. As such, it could easily be dispensed with. However, 
as shown by experience with APL and the other languages that support it, implicit map- 
ping is extremely useful. (The lack of reliable compile-time type information makes it 
Impractical to support implicit mapping in Lisp.) 

User-defined series procedures. As shown in the examples below, series proce- 
dures in Pascal are simply procedures that either have series inputs or return series values. 
As with series in general, all such definitions are handled directly by the preprocessor. 
There is no need for any special kind of declaration. Pascal does not support the concept 
pf macros. 

Example. The following example illustrates how series expressions can best be used 
: n Pascal. As in the last section, all of the expressions are optimizable. The example 

■evolves around a job queue data abstraction that might be used in an operating system. 
The basic type definition is shown below. A JobQ is a pointer to a chain of entries 

hat point to records describing jobs. These records have a number of fields including a 
numerical priority. 

type JobQ * f JobQentry; 

type JobQentry ■ record; Job: Joblnfo; Rest: JobQ end; 

type Joblnfo ■ fJobRecord; 

type JobRecord » record Priority: Real; ... end; 

There are a number of procedures defined that operate on job queues. These proce- 
dures include putting a new job onto a queue (shown below) and removing a job from a 
queue (discussed near the end of this section). To add a job onto a queue, one merely 
needs to allocate a new queue entry and attach it to the front of the queue. 

procedure AddToJobQ (J: Joblnfo; var Q: JobQ); 

var E: | JobQentry; 
begin 

new(E) ; 

Ef.Job := Joblnfo; 

EJ.Rest := Q; 

Q := E 
end 
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In addition to ordinary procedures that operate on job queues, it is useful to define 
a number of series procedures that operate on job queues. In particular, as with any 
agg regate data structure, it is useful to have procedures ScanJobq and Collect JobQ that 
cor vert job queues to series of jobs and vice versa. It also turns out to be useful to have 
a p :ocedure ScanJobQtails that enumerates all of the tails of a queue (i.e., (Q , Q| .Rest , 

Restf.Rest, ...)). As shown below, ScanJobQtails can be implemented using the 
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function ScanJobQtails (Q: JobQ): series of JobQ; 
function JobQrest (Q: JobQ): JobQ; 

begin JobQrest :■ Qf.Rest end; 
function JobQnull (Q: JobQ): Boolean; 
begin JobQnull :« Q«nil end; 
begin 

ScanJobQtails :» ScanFn(Q, JobQrest, JobQnull) 
end 

A.mong other things, ScanJobQtails can be used to implement ScanJobQ as shown 
below. The expression Qsf.Job causes the operations of following a pointer and select- 
ing the job field of a JobQentry to be implicitly mapped over the pointers returned by 
ScajjiJobQtails. 

function ScanJobQ (Q: JobQ): series of Joblnfo; 

var Qs: series of JobQ; 
begin 

Qs :* ScanJobQtails (Q) ; 

ScanJobQ :■ Qsf.Job 
end 

The procedure RemoveFromJobQ removes a job from the end of a queue. It can be 
implemented using ScanJobQtails as shown below. To start with, RemoveFromJobQ enu- 
merates the tails of the queue and uses CollectLast and Previous to obtain pointers to 
the last and next to last entries in the queue. The job field of the last queue entry is 
returned as the result of RemoveFromJobQ. (It is assumed that there must be at least one 
job in the queue.) The rest pointer in the next to last entry is set to nil, in order to 
rem 3ve the last entry from the queue. (If there is no next to last entry, the queue variable 



f is set to nil.) The storage associated with the last entry is then freed 

function RemoveFromJobQ (var Q: JobQ): Joblnfo; 
var Qs: series of JobQ; 

NextToLast, Last: JobQ; 
begin 

Qs := ScanJobQtails (Q); 
Last := CollectLast (Qs, nil); 

NextToLast :* CollectLast (Previous (Qs, nil), nil); 
RemoveFromJobQ :■ Last |. Job; 
if NextToLast=nil 
then Q := nil 

else NextToLast. Rest :« nil; 
dispose (Last) 
end 
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The first three lines of the body of RemoveFromJobQ are a series expression, while the 
remainder are non-series expressions. From an efficiency standpoint, it should be noted 
that since there is only one instance of Scan JobQt ails, the series expression is converted 
into a loop that only traverses the queue once. 

As a final example of the use of optimizable series expressions, consider the procedure 
SuperJob below. This procedure inspects a job queue and returns the last (i.e., longest 
queued) job in the queue whose priority is more than two standard deviations larger than 
the average priority of the jobs in the queue. If there is no such job, nil is returned. The 
first five statements in the procedure compute the mean and deviation of the priorities. 
The next two statements select the jobs that have sufficiently large priorities. The final 
line selects the last of these jobs, if any. 

function SuperJob (Q: JobQ) : Joblnfo; 

var Jobs, Super Jobs: series of Joblnfo; 
N: Integer; 

Mean, SecondMoment , Deviation, Limit: Real; 
begin 

Jobs :* ScanJobQ(Q); 

N :- Collect Length ( Jobs) ; 

Mean :« CollectSum( Jobs. Priority) /N; 

SecondMoment :« CollectSum(Sqr( Jobs. Priority ))/N; 

Deviation :« Sqrt(SecondMoment-Sqr(Mean)) ; 

Limit :* Mean+2*Deviation; 

SuperJobs := Choose ( Jobs. Priority>Limit, ScanJobQ(Q)) ; 

SuperJob := CollectLast (SuperJobs, nil) 
end 

The programs above are a good example of the way series expressions are intended to 
be used. To start with, all of the programs are straightforward in nature. This reflects 
the fact that the primary goal of series expressions is to convert the vast majority of 
programs that are in fact straightforward programs into dirt simple programs. When 
a. program is straightforward, it is usually easy to write it in a loop-free form without 
having to use anything other than very simple series expressions. 
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6. The Optimization Algorithms 

A preprocessor or compiler extension that transforms optimizable series expressions 
into loops can be implemented in three stages: parsing which locates optimizable expres- 
sions and converts them into equivalent data flow graphs, pipelining which converts the 
expressions into loops, and unparsing which converts the resulting loops into appropriate 
program code and inserts this code in place of the original expressions. 

Below, the Pascal implementation of series is used as a concrete illustration. The 
Co]nmon Lisp implementation works in the same way, except that the characteristics of 
Lis ) simplify the parsing and unparsing stages. 

Parsing. When the preprocessor is applied to a program, it begins by parsing the 
program. Series expressions are located by inspecting the types of the procedures called 
by the program. While this is being done, the static analyzability and straight-line 
con Lputation restrictions are checked and any violations reported. 

[n a language like Pascal where complete compile-time type information is available, 
implicit mapping can be supported by noting places where non-series functions are ap- 
plied to series. Each such application is replaced by an appropriate use of MapFn. 

The final action of the parsing stage is to create a data flow graph corresponding to 
each optimizable series expression located. Since each of these expressions is a straight- 
computation, this is easy to do. Each procedure call becomes a node in the graph 
the data flow between the nodes is derived from the way procedure calls are nested 
the way variables are used. 

Pipelining. The operation of the pipelining stage is illustrated in Figure 6.1. The 
serius expression in the procedure SumSqrs (which computes the sum of the squares 
of the odd elements of a vector) is transformed into the loop shown in the procedure 
Sum:5qrsPipelined. The readability of the loop code is reduced by the fact that it con- 
tains a number of internally generated variables. However, the code is quite efficient. The 
only significant problem is that the pipeliner sometimes uses more variables than strictly 
necessary (e.g., Results). However, this need not lead to inefficiency during execution as 
long as a compiler capable of simple optimizations is available. 

The pipelining process operates in several steps. In the first step, the divide and 
conquer strategy discussed in Section 2 is used to partition the data flow graph for a 
series expression into subexpressions where all the data flow connects on-line ports. While 
doing this, the pipeliner checks that the expression obeys the sequence intermediate value 
and on-line cycle restrictions. 

Once partitioning is complete, the procedures in each subexpression are combined into 
a single procedure. The resulting procedures are then combined based on the data flow 
between the subexpressions. To support the combination process, each series procedure 
is represented as a loop fragment with one or more of the following parts: 
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function SumSqrs (V: array [1..N] of Integer): Integer; 
begin 

SumSqrs := CollectSum(Sqr(ChooseIf (Odd, Scan(V)))) 
end 

function SumSqrsPipelined (V: array [1..N] of Integer): Integer; 
label 0,1; 

Var Element 12, Indexl5, Result5, Sum2: Integer; 
begin 
[1] Indexl5 := 0; 
[4] Sum2 :■ 0; 
[1] 1: Indexl5 := 1+Indexl5; 
[1] if Indexl5>N then goto 0; 
Cl] Element 12 :« V[Indexl5] ; 
[2] if Odd (Element 12) then goto 1; 
[3] Result5 :* Sqr (Element 12) ; 
[4] Sum2 :■ Sum2+Result5 ; 
goto 1; 
0: SumSqrsPipelined :* Sum2 
end 



[1] — Scan of a vector 

inputs- Vector: array IK. .L] of ElementType; 
outputs- Element: Series of ElementType; 
vars- Index: Integer; 
prolog- Index: 1-K; 

body- Index :■ 1+Index; 

if Index>L then goto 0; 
Element :* Vector [Index] ; 

[2] — Chooself 

inputs- function P(X: ElementType): Boolean; 
Item: Series of ElementType; 
outputs- Item: Series of ElementType; 
labels- 2; 

body- 2: Nextln(Item) ; if P(Item) then goto 2; 

[3] — Implicit mapping of Sqr 

inputs- Item: Series of ElementType; 
outputs- Result: Series of ElementType; 
body- Result := Sqr ( Item) ; 

[4] — CollectSum 

inputs- Number: Series of ElementType; 
outputs- Sum: ElementType; 
prolog- Sum := 0; 

body- Sum := Sum+Number; 

Figure 6.1: Transforming optimizable series expressions into loops. 
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inputs- Input variables, 

outputs- Output variables. 

vars- Auxiliary variables used by the computation, 

labels- Labels used by the computation, 

prolog- Statements that are executed before the computation starts. 

body- Statements that are repetitively executed, 

epilog- Statements that are executed after the loop terminates. 

The bottom part of Figure 6.1 shows the fragments that represent the procedures 
called by the series expression in SumSqrs. These fragments are combined to create the 
loo ) in SumSqrsPipelined. The numbers in the left hand margin indicate which fragment 
eaci line of the loop comes from. Two different combination algorithms are used: one 
corresponding to data flow between on-line ports and one corresponding to data flow 
tou :hing off-line ports. 

When two procedures are connected by data flow connecting on-line ports (e.g, the 
data, flow from the output of Sqrs to the input of CollectSum), the procedures are corn- 
bin id by simply concatenating the various parts of the corresponding fragments together. 
In i addition, the variables and labels in the fragments are renamed so that there will be 
no possibility of conflicts. The data flow between the procedures is implemented by re- 
naming the input variable of the destination so that it is the same as the output variable 
of the source. (The process above is much the same as an application of the standard 
con piler optimization technique of loop fusion [3].) 

When two procedures are connected by series data flow terminating on an off-line 
input (e.g., the data flow from the output of Scan to the series input of Chooself in the 
figure), the fragment representing the destination procedure contains an instance of the 
forri Nextln, which specifies when elements of the input should be computed. The two 
frag ments are combined exactly as in the on-line combination algorithm except that the 
body of the source fragment is substituted in place of the call on Nextln, rather than 
beii g concatenated with the body of the destination fragment. (This process essentially 
con piles in support for a simple case of lazy evaluation [16].) 

Jnparsing. The result of pipelining is a single loop fragment that corresponds to 

series expression as a whole. In the unparsing stage, this fragment is converted into 
a loop as indicated below. The combination process eliminates the inputs. The other 
parts of the fragment appear directly in the loop except for the outputs. 

label 0,l,iabeis; 

var vars; 
begin 

prolog; 
1: body; 

goto 1; 
0: epilog; 



into 



?he outputs are connected up to the surrounding code when the loop is substituted 
the program in place of the original series expression. Once each series expression has 



beeil replaced by a loop, the resulting code can be passed to a standard Pascal compiler. 



Systems Based on Similar Algorithms 35 

Side-effects. The correctness preserving nature of the transformations above has 
been shown under the assumption that there are no side-effects involved. It is believed 
that if unoptimized series are implemented as shown in the beginning of Section 4, the 
transformations are also correctness preserving in the presence of side-effects. The reason 
for this is that the transformed code exactly mimics the lazy evaluation of the untrans- 
formed expression. For instance, the off-line port combination algorithm involves code 
motion; however, this motion simply moves the generation of the series elements to the 
place where lazy evaluation requires the elements of the series to be first computed. 

The above can be made more formal from the point of view of path analysis [10]. 
Path analysis seeks to determine at compile time where in a program each lazy value will 
be first used and where it will be reused. This information can be used to optimize lazy 
evaluation in two ways. If there is an identifiable place of first use of a given value then 
ordinary evaluation can be used instead of lazy evaluation for that value. If there is an 
identifiable last use for a value, the value does not have to be stored beyond that time. 

The restrictions in Section 2 guarantee that for each series, there is an identifiable 
place where each element of the series is first used and that, for each element, the last 
use precedes the computation of the next element. The transformations above merely 
position the computation of the elements at their place of first use and omit their long 
term storage. 

The above notwithstanding, one should realize that side-effects are still problematical, 
because lazy evaluation makes it difficult for programmers to figure out what the net 
results of side-effects will be. Some situations can be readily understood. For example, 
one can depend on the fact that mapping will apply the mapped function T first to the 
first element of the input, then to the second, and so on in strict temporal order. Thus, 
iT interacts with itself or the environment outside of the containing series expression X 
via side-effects (e.g., by doing input or output), but does not interact with anything else 
in X, the result is easy enough to understand. More complex uses of side-effects should 
:>e avoided. 

Systems Based on Similar Algorithms 

The algorithms above have evolved into their current form over the past twelve years. 
The first generally available implementation was a Lisp macro package called LetS [42, 
43]. The current Lisp implementation [46] is available in Portable Common Lisp. 

The same basic approach to representing and combining sequence procedures was in- 
dependently developed by Wile [48]. However, he does not explicitly address the question 
of restrictions and his approach does not guarantee that every intermediate sequence can 
be eliminated. Much the same can be said about APL compilers [11]. 

A quite similar approach is also used internally by the Loop macro [12]. However, 
as discussed in the next section, the Loop macro is externally very different from se- 
ries expressions. In particular, it uses an idiosyncratic English-like syntax rather than 
Representing computations as compositions of procedures operating on series. 
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7. Comparisons 

There are two primary vantage points from which to compare series expressions with 
rekted concepts. The most obvious comparison is with other support for sequence ex- 
pre ssions. From this perspective, the key feature of series expressions is that they support 
mo: it of the operations supported by the vector operations of APL [31], Common Lisp 
seqience operations [36], and the stream operations of Seque [19] (along with a few 
additional ones) while being more efficient. 

Another way to view series expressions is that they are a logical continuation of the 
trei.d in programming language design toward supporting the reuse of loop fragments. 
From this point of view, series expressions extend the approach taken by iterators in 
CLl [27] and the Lisp Loop macro [12]. The key feature of series expressions in this 
context is that they support the reuse of a wider variety of fragments and are easier to 
und erstand and modify, without being any less efficient. 

To lend depth to the comments above, the remainder of this section presents detailed 
comparisons between the Common Lisp implementation of series expressions and five 
other systems. Each of these comparisons features the example below. This example 
shows the definition of a procedure that computes the sum of the positive elements of 
a vector. It also illustrates how a new series procedure can be defined. (The example 
assumes the existence of a procedure Positive that tests whether an integer is greater 
thai zero.) 

function SumPositive (V: array [1..N] of Integer): Integer; 
begin 

SumPositive := CollectSum(ChooseIf (Positive, Scan(V))) 
end 

function CollectSum (S: series of Integer): Integer; 
begin 

CollectSum := CollectFn(0, +, S) 
end 



Other Support for Sequence Expressions 

there are many programming languages that provide support for sequence expres- 
sions, e.g., [5, 6, 19, 25, 32, 34, 35, 36]. So many, that it would not be practical to make 
detc iled comparisons between each one of these languages and series expressions. Three 
representative languages are discussed below. 

APL. One of the oldest and must used languages that takes a functional approach is 
APL [23, 31]. A style of writing APL has evolved where vector expressions are used instead 
of loops. The correspondence between the series functions discussed in Section 3 and the 
APL vector operators is summarized in Figure 7.1. The APL concept of the extension of 
scalar operations to vectors corresponds to implicit mapping. 

As illustrated below, both the vector summation algorithm and user-defined sequence 
procedures can be very compactly represented in APL. Since each sequence is directly 
represented as a vector, there is no need for an operation analogous to Scan. 
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The key differences between APL and series expressions are that APL vectors cannot 
represent unbounded sequences, the set of APL operations is somewhat different, and 
users are not given any feedback about what is efficient and what is not. 

Although all the series operations could have been supported in APL, there is no direct 
built-in support for scanning, mingling, or chunk. In addition, APL does not support 
higher-order operations as well as it might initially appear. For instance, the reduction 
operator appears to be a higher-order operation. However, at least in standard APL, the 
operation to be reduced must be one of the predefined scalar operations— user-defined 
operations cannot be used. As a result, the reduction operator is actually just part of a 
naming scheme for a small set of specific collectors. (This has the collateral benefit of 
allowing the initial identity value to be implicit.) 

APL supports four operations (reversal, membership, grade up, and grade down) that 
ire not supported by series expressions because they cannot be implemented in a preorder 
fashion using bounded storage. APL also allows the modification of the elements of a 
sequence. When using series expressions, one has to rely on other constructs in the host 
anguage when performing any of these operations. For instance, to sort a series in the 
Lisp implementation of series, one must first collect the series into a list and then sort 
the list. Explicitly creating a list makes the expensive nature of sorting more obvious, 
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Figure 7.1: The correspondence between series functions and APL operations. 
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hov ever, it does not make sorting more expensive, because sorting requires that some 
ph} sical representation of the sequence be created. 

A. few APL compilers [11, 21] are capable of producing efficient code in most of the 
situations where series expressions can be optimized; however, most are not. As a result, 
opt mizable series expression are typically much more efficient. Further, even when the 
con ipiler supports optimization, programmers are not given any feedback about whether 
opt mization will occur. Rather, programmers are (at least implicitly) encouraged not to 
thii.k about such issues. 

An area where APL is fundamentally more powerful than series expressions is that 
the standard intermediate structure in APL is the array. APL has a number of powerful 
amy operators (not shown in Figure 7.1) and a few APL compilers can optimize some 
amy expressions. In contrast, while it is possible to have series of series, there are no 
spe dal series operations for operating on them, and they are never optimized. 

Finally, a superficial but striking difference between series expressions and APL is that 
seri >s expressions use standard subroutine calling notation while APL uses a special set 
of concise, but cryptic, operators. 

Oommon Lisp Sequence Operations. While many (if not most) Lisp program- 
mer s use loops extensively, a style of writing Lisp has evolved where expressions corn- 
put ng intermediate lists and vectors are used instead of loops. Unfortunately, until 
rea ntly, Lisp supported an impoverished set of predefined sequence operations— it sup- 

ed mapcar, but not much else. When Common Lisp was designed [36], this defect 

rectified by introducing a relatively comprehensive suite of sequence operations. 

n Common Lisp, the term 'sequence' is used to refer to either a list or a vector. How- 
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Figure 7.2: The correspondence between series functions and sequence operations. 
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^ver, since both of these structures are limited to representing bounded sequences, Lisp 
sequences are not a complete implementation of mathematical sequences. The correspon- 
dence between the basic series functions and the Lisp sequence operations is summarized 
in Figure 7.2. Lisp does not support implicit mapping. 

The example below shows how the Common Lisp sequence operations can be used to 
express the vector summation algorithm and a user-defined sequence procedure. Since a 
vector is a Lisp sequence, there is no need for a procedure analogous to scan. 

(defun sum-positive-sequence (v) 

(collect-sum (remove-if-not t'plusp v))) 

(defun collect-sum (numbers) 
(reduce #'+ numbers)) 

Except for the fact that Lisp sequences cannot represent unbounded sequences, there 
is no reason why all the series functions could not be supported by sequence operations. 
However, there is no direct built-in support for scanning, collecting, spreading, or chunk, 
n addition, the identity value to use for reduce (collection) is specified in an odd way. 
The procedure argument must be implemented in such a way that when called with zero 
Arguments it returns the identity value. 

Current Lisp compilers do not optimize sequence expressions. As a result, optimizable 
series expressions are much more efficient. In light of the lack of optimization, it is not 
surprising that Lisp provides no feedback about optimizability. As in APL, there is no 
Dias toward preorder functions and modification of sequence elements is allowed. It is 
ilso common to have sequences of sequences, however, Lisp does not provide any special 
operations for manipulating them. 

An interesting aspect of the Lisp sequence operations is that they typically support 
1 number of keyword arguments that modify their behaviors. For example, consider 
:he sequence operation count- if , which takes a predicate and a sequence, and returns a 
;ount of the number of elements in the sequence that satisfy the predicate. 

(count-if #'plusp '(1 -2 3 4 -5)) => 3 

The Lisp operation count-if takes two keyword arguments : start and :end, which 
:an be used to specify a subsequence of the input in which counting is to occur. In 
addition, a keyword argument :key can be used to specify an access procedure that will 
)e used to fetch the part of each sequence element that should be tested by the predicate, 
finally, an operation count-if -not exists, which is the same as count-if except that it 
mtomatically negates the values returned by the predicate. 

As illustrated by the example below, none of these options is strictly necessary. The 
start and :end keywords can be dispensed with by using subseq. The :key keyword 
ind count- if -not can be dispensed with by specifying complex predicates. 

(count-if-not #'plusp »((1) (-2) (3) (4) (-5)) 
: start rend 3 :key #' first) 
= (count-if #' (lambda (element) (not (plusp (car element)))) 
(subseq '((1) (-2) (3) (4) (-5)) 3)) ^ 1 
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Nevertheless, the various options described above are important for two reasons. First, 
promote efficiency. (Using subseq instead of the : start and rend keywords is ineffi- 
cierit, because it creates an intermediate sequence.) Second, they increase the probability 
predefined operations can be used as procedure arguments instead of lambda expres- 
sions. This makes uses of count -if more concise and easier to read. 

Using series expressions, neither of these issues comes up. In the Lisp series expression 
r, the use of subsories does not lead to inefficiency, since pipelining eliminates the 
physical creation of its output series. Convenient support for mapping makes it possible 
to c void the need for an explicit lambda expression. The desired test and key is simply 
mapped over the series in question (again without inefficiency). Finally, count -if itself 
be dispensed with by using a combination of choose and collect-length. The 
approach taken by series expressions allows the individual procedures to be simpler and 
males things more functional in appearance. 

(let ((elements (subseries (scan '((1) (-2) (3) (4) (-5))) 3))) 
(collect-length (choose (#Mnot (#Mplusp (#Mcar elements)))))) =>■ 1 
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Seque. Under the name of streams, sequences are the central data type of the 

;uage Seque [19]. Using the same basic lazy evaluation technique discussed in the 
beginning of Section 4, Seque supports both bounded and unbounded sequences. The 

espondence between the series functions discussed in Section 3 and the stream opera- 
provided by Seque is summarized in Figure 7.3. As in APL, many of these operations 

provided by means of special syntax. In addition, implicit mapping is supported for 
mafy non-stream operations when they are applied to streams. 
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Figure 7.3: The correspondence between series functions and Seque operations. 
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As illustrated below, both the vector summation algorithm and user-defined sequence 
procedures can be easily represented in Seque. Since streams are a distinct data type 
from vectors, an operation ! equivalent to Scan is required. 

procedure SumPositive (V) 

return CollectSum([: !V: lambda(e) if e>0 then e] ) 
end 

procedure CollectSum (S) 

L :* Length (S) 

return if L=0 then else Red(S, n +")!L 
end 

Since unbounded sequences are supported, it would be easy to completely support all 
;he series functions in Seque. However, there is no direct support for mingling, spreading, 
)r chunk. In addition, collection is only indirectly supported by collecting, this leads 
;o awkwardness when collection is applied to an empty sequence, because there is no 
ipecification of the correct default value to return. There is also no direct support for 
he higher-order function scanning. However, there is an impressive array of facilities for 

defining scanning functions, both in Seque and in the language Icon [18], which Seque is 
msed on. It is interesting to note that like the series operations, all of Seque's stream 

Operations are preorder. 

Seque does not attempt to optimize the evaluation of stream expressions by eliminat- 
ng the computation of unnecessary intermediate streams. As a result, series expressions 
ire never less efficient and often much more efficient. Seque programmer's are encouraged 
o think in terms of streams of streams and to make use of assigning to the elements of 

: treams without any regard for the consequences on efficiency. 

Summary. In comparison with the languages above, series expressions have three 

principal advantages. They support a wider range of operations than any one of the 
anguages. Except in comparison with the best of APL compilers, they are much more 

( efficient. They give clear feedback about what is efficient and what is not. As part of this, 
hey make the use of non-preorder procedures more awkward, by forcing the programmer 
o use the facilities of the host language. 

Looping Notations 

The fundamental virtues of series expressions in comparison with looping constructs 
are illustrated by the discussion in the beginning of Section 1. However, this discussion 
i s colored by the fact that it illustrates the use of only the most basic kind of looping 
< instruct. More complex looping constructs support several of the features of series 
i sxpressions. In particular, they allow the equivalent of scanners and collectors (but not 
1 ransducers) to be expressed as localized forms rather than as a statements dispersed in 

iJL loop. 

Most programming languages contain a for construct, which makes it easy to express 

oops that are based on enumerating a range of integers (i.e., they support a standard 

loop fragment analogous to scan-range). Some languages go beyond this by providing 

sjpecial looping forms corresponding to a few additional scanners. For example, Common 

,isp provides a form dolist that makes it easy to implement a loop based on scanning 
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the elements of a list. A couple of languages go further still by supporting a relatively 
wide range of standard looping fragments. Some of the oldest and most comprehensive 
sup )ort for this is in Lisp. 

The Lisp Loop macro. The Lisp Loop macro [12] (which is based on the iterative 
statements in the InterLisp Clisp facility [37]) introduces two concepts into Lisp. First, 
it si Lpports a looping construct analogous to for that uses an Algol-like keyword syntax. 
Sea >nd, it goes way beyond most for constructs by supporting a wide range of looping 
fragments analogous to scanners and collectors. Because of its non-Lisp syntax, the Loop 
mac ro has always been controversial. However, because of the utility of its predefined 
looping fragments, it has gained wide use. 

The example below shows a program that uses the Loop macro to implement the 
vecl or summation algorithm. It also shows how a keyword vector-element (which cor- 
restonds to scanning a vector) could be defined. (The Loop macro does not support 

definition of new collector- like fragments.) The code produced by the Loop macro 
is more or less identical to the code produced when optimizable series expressions are 
pipelined. As a result, the two approaches are equally efficient. 



(defun sum-positive-loop-macro (v) 

(loop for item being each vector-element of v 
when (plusp item) 
sum item)) 

(define-loop-path vector-element scan-vector (of)) 

(defun scan-vector (path-name variable data-type prep-phrases 

inclusive? allowed-prepositions data) 
(declare (ignore path-name data-type inclusive? 
allowed-prepositions data)) 
(let ((vector (gensym)) 
(i (gensym)) 
(end (gensym))) 
'(((, vector) (,i0) (,end) (, variable)) 
((setq , vector , (cadar prep-phrases)) 

(setq ,end (- (length , vector) 1))) 
(> ,i ,end) 

(.variable (aref , vector ,i)) 
nil 
(,i (+ ,i 1))))) 

x>op supports a keyword when that is similar to the transducer choosing (see the 
example). A call on the Loop macro can also contain an arbitrary body that is mapped 
ovei the values computed by the scanner-like fragments (this is not shown in the example). 
Hov ever, the Loop macro does not support any other transducer-like looping fragments. 

, V subtle difficulty with the Loop macro is that there are no restrictions on the com- 
putation that can be in the body and there is no attempt to prevent the body from 
interfering with the computation specified by the looping fragments. As a result, pro- 
grar imers cannot depend on the fact that these fragments will necessarily do what they 
are ntended to do. 

i Another problem with the Loop macro is that the facilities provided for defining the 
equivalent of new scanners are quite cumbersome. The user has to define a procedure that 



pooping Notations 43 

[ieals with parsing parts of the Loop syntax and that returns a list of six parts analogous 
to the parts of the loop fragments discussed in Section 6. (Recently, the Common Lisp 
standardization committee decided to adopt most of the Loop macro as part of Common 
pisp. However, on the grounds that it is too complex, they decided not to include the 
^canner-defining form.) 

The concept of Generators and Gatherers presented in [29], provides essentially the 
same capabilities as the Loop Macro, but with a more functional syntax and simpler 
[defining forms. 

Iterators in CLU. Among Algol-like languages, some of the most powerful support 

for the use of looping fragments is provided by CLU [27]. In CLU, scanner-like fragments 

ailed iterators can be used in for loops to generate a series of elements that are processed 

»y the body of the for. CLU provides a number of predefined scanners including one 

orresponding to scanning a vector and users can define new ones. (Alphard [49] supports 

construct called a generator that is essentially identical to a CLU iterator.) 

As an illustration, the example below shows how the vector summation algorithm can 

:>e expressed in CLU. It also shows the definition of a user-defined scanner. This is done 

Dy writing a coroutine that yields the scanned elements one at a time. 

SUM_POSITIVE_CLU = proc(V: ARRAY[INT]) returns(INT) 

SUM: INT := 

for ITEM: INT in SCAN.VECTOR(V) do 

if ITEM>0 then SUM :* SUM+ITEM end 

end 

return (SUM) 
end SUM.POSITIVE.CLU 

SCAN. VECTOR = iter(V: ARRAY[INT]) yields(INT) 
I: INT :« ARRAY [INT] $L0W(V) 
END: INT :* ARRAY [INT] $HIGH(V) 
while K=END do 
yield(V[I]) 
I := 1+1 
end 
end SCAN.VECTOR 

Taken together, CLU iterators and the for statement are essentially the same as the 

oop macro except for three things. Nothing besides mapping and scanning is supported. 

In the example above, the operations of choosing and summing are both represented in 

ion-local ways in the body of the loop.) Each for can only contain one iterator instead 

of many. CLU's method for defining iterators as coroutines is significantly easier to use 

han the Loop macro's scanner- defining form. 

A method for supporting multiple iterators in a CLU for statement is described in 

14]. Going beyond this, [13] describes how one could support collectors (again restricted 

o only one in each loop). While both of these papers merely present proposals rather 

han describing actual implementations, there is no doubt that everything supported by 

1 he Lisp Loop macro could be straightforwardly supported in an Algol-like language. 

Summary. The key difference between the looping constructs above and series ex- 
pressions is that while the looping constructs support looping fragments corresponding to 
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(potentially unbounded) scanners and collectors and are highly efficient, they do not sup- 
port the concept of a sequence data structure nor the idea of treating loop fragments as 
procedures. This preserves the iterative feel of the constructs, however, it is significantly 
limiting in several ways. 

The lack of a sequence data type prevents the constructs from supporting anything 
other than a few simple transducers. (It is not clear how one could support transducers 
in g eneral without having some kind of object that they can act upon.) 

The fact that the loop fragments are not procedures means that the way the fragments 

be used is intimately tied up with the syntax of the constructs. One has to learn a 
language of combination rather than simply using standard functional composition. 
In addition, this new language of combination is much more restricted than functional 
con position. For instance, the only thing that can be done with a scanner-like fragment 
is to use it in a call on loop or for and map some computation over the values scanned. 

An interesting thing to note about the looping constructs above is the way they avoid 
getting involved with a discussion of the restrictions in Section 2. By not allowing a 
sequence data structure to be stored in a variable, only supporting preorder fragments, 
largely ignoring transducers (particularly off-line ones), and limiting the way fragments 
be combined, the constructs implicitly enforce these restrictions without having to 
talk about them. Unfortunately, the total restrictions they embody are much stronger 
than the ones in Section 2. This unnecessarily limits what can be expressed. 
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There are three principal perspectives from which to view series expressions. To 
start with, series expressions can be looked at as embodying relatively complete support 
for sequence expressions in such a way that they can be included in any programming 
language without: removing any preexisting features of the language, requiring the use 
of unusual syntax, or causing inefficiency. This support includes most of the operations 
provided by languages such as APL, Lisp, and Seque along with a few additional ones. 

An alternate perspective focuses on the fact that programmers are given clear and 
immediate feedback about the efficiency of the series expressions they write. Series 
expressions that do not violate the restrictions in Section 2 are guaranteed to be as 
effic lent as they look. By means of error messages, programmers are encouraged to think 
of e : ficient methods for computing the results they want. In particular, unlike APL, Lisp, 
or Seque, programmers are never tempted to think that all sequence expressions are 
equfdly efficient. 

final perspective is summarized by the statement that "optimizable series expres- 
sions are to loops as structured control constructs are to gotos." By using optimizable 
seriejs expressions, it is possible to banish loops from most programs. Given that expres- 
sions are much easier to understand and modify than loops, this has the potential for 
being a step forward at least as important as banishing gotos. 

While the idea has not yet been explored, optimizable series expressions might also be 

helpful in the context of parallelism. Even though it is optimized for sequential machines, 

the pipelining applied to optimizable series expressions is very much the same as the 

software pipelining' of loops for execution on very large instruction word machines [26] 
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md for execution by the processors of a systolic array [2, 20]. If programs were written 

ising series expressions, the process of analyzing the programs to determine a good 

; schedule for the pipelined computation might be simplified. In addition, the restrictions 

n Section 2 appear relevant, because buffering of elements also causes inefficiency in a 

parallel context. 

The application of optimizable series expressions to non-pipelined parallelism is less 
rlear. The emphasis in such situations is on locating opportunities for evaluating sub- 
romputations completely in parallel with no data flow between them. This is appropriate 
or mapping, but not for most of the other series operations. Nevertheless, using opti- 
nizable series expressions might make it easier to detect where such parallelism exists, 
^or example, this might make it easier to 'vectorize' [4] programs. 
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